Dumitrascu Analizasiproiectare

Stelian Guu Gabriel Marcu
Liviu Dumitracu (coordonator) Liviu Ioni Bogdan Dumbrvescu
Analiza i proiectarea orientat obiect a sistemelor informatice cu UML
Editura Universitii din Ploieti 2005
1 Modelare i UML
n acest capitol: Despre modelare, principii de modelare, limbaje de modelare Metodologii de realizare a sistemelor informatice UML standard industrial de modelare obiect Tipuri de diagrame UML
Despre modelare, principii de modelare, limbaje de modelare

De cele mai multe ori, n viaa de zi cu zi, avem de-a face cu modele. Astfel, atunci cnd vorbim despre avioane sau automobile, avem n minte anumite caracteristici sau aspecte ale acestor obiecte, de pild viteza sau forma lor aerodinamic. Aceasta nseamn c am redus ntregul obiect, n cazul de fa destul de complicat, la un model simplu, care se deplaseaz repede i are o form alungit cu muchii rotunjite, pentru a susine o teorie sau a demonstra ceva. Celelalte caracteristici, ca de exemplu consumul de carburani, preul sau costul ntreinerii, au fost neglijate cu bun tiin pentru c nu erau relevante pentru teoria noastr. La fel, atunci cnd ne referim la cunotine, prieteni sau, dimpotriv dumani, neglijm, de cele mai multe ori, aspectul lor fizic i ne referim la modelul lor psihologic sau comportamental verificat n relaiile cu propria noastr persoan. n general, spunem c nu putem trece la a realiza ceva, fr a avea n minte, la nceput vag dar mai apoi din ce n ce mai detaliat, un model al obiectului pe care dorim s-l construim. Dac ne referim la sistemele informatice, acestea reprezint ele nsele modele informaionale ale activitilor noastre n cele mai diverse domenii producie, servicii, comer, politic, administraie. Proiectul unui sistem informatic reprezint planul de realizare al unui asemenea sistem i pleac, evident, tot de la un model, care reduce sistemul final la elementele lui eseniale permind abordarea sa sistematic i controlul pe parcursul execuiei. Aceasta permite coordonarea
echipelor de realizare a proiectului prin verificarea stadiului la care s-a ajuns fa de ceea ce era planificat, precum i elaborarea documentaiei de proiectare.
Modelul este, prin urmare, o reprezentare abstract a unui sistem, care permite planificarea, studiul, analiza, concepia i verificarea performanelor sistemului nainte de realizarea sa propriu zis, precum i crearea documentaiei de proiectare, facilitnd totodat comunicarea ntre echipele de proiectare.
Modelul se dovedete deosebit de util n trei faze diferite ale proiectrii: n specificarea cerinelor noului sistem, n activitatea de analiz a sistemului proiectat, precum i n activitatea de formulare a soluiei informatice pentru sistemul proiectat i realizare a acestuia. Modelul contextului (n specificarea cerinelor) Sistemul proiectat este considerat ca subsistem (cutie neagr), care funcioneaz n cadrul unui sistem mai larg (de exemplu, ntreprinderea sau segmentul de pia al acesteia). Se dezvolt un model de nivel context care precizeaz limitele funcionale ale sistemului proiectat. Modelul sistemului proiectat (n activitatea de analiz) Modelul reprezint sistemul proiectat, vzut din interior. Acesta se compune din obiecte care reprezint o abstractizare a conceptelor manipulate de utilizator precum i relaiile dintre acestea. Se au n vedere: structura static i comportamentul dinamic al sistemului. Modelul soluiei informatice (n activitatea de realizare) Modelul corespunde mijloacelor de realizare efectiv a sistemului proiectat i evideniaz conceptele informatice utilizate ca instrumente, limbaje sau platforme de dezvoltare. Modelul servete la studierea i anticiparea unei soluii.
Observaie. Este de preferat s se descopere o eventual eroare de concepie pe un model, dect n faza de exploatare sau de testare a sistemului deja realizat.
Primul principiu: Alegerea modelelor influeneaz esenial maniera de abordare a problemelor i soluionarea lor. Cu alte cuvinte, dac este ales bine un model
Lucrrile de specialitate menioneaz urmtoarele patru principii ale modelrii 1:
poate aduce clarificri nesperate alegerii celei mai bune soluii, n timp ce o alegere greit a modelului poate abate atenia dezvoltatorilor de la unele probleme fundamentale. Practica arat c orientarea obiect conduce la cele mai
[BRJ] Booch Grady, Rumbaugh James, Jacobson Ivar Le guide de lutilizateur UML, Edition Eyrolles, 2000, pp.8-10 (trad.l.engl. The Unified Modeling Language User Guide, Addison-Wesley, 1998).
bune rezultate pentru construirea unor sisteme informatice care se sprijin pe arhitecturi flexibile, chiar dac majoritatea activitilor const n calcule sau lucrul cu baze de date. Al doilea principiu: Modelele pot avea diferite niveluri de precizie. Cele mai bune modele sunt acelea care las la latitudinea proiectantului alegerea nivelului de detaliu pn la care s se coboare n realizarea diferitelor subsisteme, n funcie de ceea ce se urmrete i care sunt resursele disponibile. Al treilea principiu: Cele mai bune modele sunt bazate pe simul realitii. Orice modelare simplific realitatea, dar nu trebuie s piard din vedere nici un detaliu important. Cu ajutorul tehnicilor orientate obiect se pot reuni ntr-un tot semantic diferitele puncte de vedere asupra unui proiect.
Pstrnd un grad redus de interdependen, se micoreaz considerabil riscul adoptrii unui singur model. Micile modele fac deosebit de oportun atribuirea lor unor echipe de proiectare diferite, care s gndeasc i s realizeze liber subsistemele de care rspund, efului de proiect fiindu-i mult mai la ndemn coordonarea acestora.
Al patrulea principiu: Deoarece nici un model nu este suficient prin sine nsui, este preferabil s descompunem un sistem mare ntr-un ansamblu de mici modele, aproape independente, care s poat fi studiate i testate separat.
Pentru a realiza un sistem, trebuie mai nti s-l modelm. Pentru a analiza un sistem, trebuie, de asemenea, s-l modelm. Modelarea are nevoie de un limbaj, n primul rnd ca mijloc de comunicare, pentru ca toi factorii implicai, constructori i utilizatori, s neleag acelai lucru 2. Iat cteva din motivaiile acestei alegeri: 1. Scopul fiecrui manager de proiect este de a putea mbunti costurile i nltura incertitudinile programului n timp ce caut s satisfac cerinele clientului. Unul din cei mai mari dumani ai supleei i adaptabilitii este automatizarea exagerat. Programele foarte complicate sunt adesea rigide, greu de modificat i n foarte scurt timp i pierd eficiena n faa evoluiei sistemelor obiect. 2. Pe de alt parte, atunci cnd pornim la construcia unui sistem avem rareori ocazia s-i cunoatem toate detaliile. Multe din caracteristici urmeaz s le descoperim pe parcurs. Interaciunea cu utilizatorul este necunoscut. Comportamentul n timp nu poate fi dect bnuit. Factori importani externi i chiar interni, crora suntem obligai s le facem fa,
De ce un limbaj de modelare?
De ce un limbaj orientat obiect?
4
[Fowler&Scott] Martin Fowler et Kendall Scott Le tout en poche - UML, 2002, Campus Press, p.15 (trad.l.engl. UML Distilled, Second Edition, Addison-Wesley Longman, Inc., 2000).
2
urmeaz s apar dup nceperea proiectului. Managerul proiectului are nevoie de instrumente pentru a stpni cerinele care pot apare, pentru a le rafina i perfeciona pe toat durata ciclului de via a proiectului. Proiectarea orientat-obiect dispune de asemenea instrumente. 3. Dezvoltarea orientat obiect include i aa-numitele cazuri de utilizare o metod de precizare i stpnire a cerinelor dinamice ale sistemului pe care o vom descrie n detaliu n cadrul acestei lucrri. Cazurile de utilizare cuprind un format pentru specificarea cerinelor dinamice, care descriu n detaliu cum va reaciona sistemul ca rspuns la interaciunea utilizatorului. Acestea formeaz o punte de legtur ntre punctul de vedere al clientului i cel al proiectantului, ajutnd la nelegerea n acelai fel a fenomenelor cu care va fi confruntat sistemul.
Metodologii de realizare a sistemelor informatice

Metodologia de realizare clasic a sistemelor informatice
Realizarea clasic a sistemelor informatice, sub forma cderii de ap n cascad (waterfall) 3, a fost conceput nc din anul 1970 i consta n 4 mari faze care se executau succesiv i integral: analiza, proiectarea, construcia i testarea. Aceast metodologie primitiv era destul de rigid i nu permitea ntoarcerea la o faz precedent pn cnd nu era terminat faza curent. ntoarcerea se fcea cu pierderi materiale mari care puneau sub semnul ntrebrii realizarea integral a proiectului. n general, nu exista o certitudine n construirea adevratului sistem pn la terminarea fazei de testare.
5
3
Vezi [LuChi-kw] Introduction to object-oriented systems development, B329 Unit 1, pag.4-22, External Course Assessor, Dr.Lucas Chi-kwong Hui, University of Hong Kong, 2003
Metoda SDLC (Systems Development Life Cycle)

Au fost realizate i metode de management pentru planificarea, execuia i controlul punerii n practic a unei asemenea metodologii clasice, cum ar fi SDLC (Systems Development Life Cycle). Acesta consta n spargerea proceselor complexe n faze i activiti. Principalele instrumente utilizate erau diagramele de relaii ntre entiti (relation diagrams) i diagramele de fluxuri de date (flowcharts). Cu toat strdania de a crea instrumente care s faciliteze realizarea practic a sistemelor informatice, SDLC pstra ns principalele inconveniente ale metodologiei clasice, menionate mai sus.
Metoda SDLC iterativ

O ameliorare a acestei metode, SDLC iterativ, a aprut mai trziu, dup anul 1980 i consta n realizarea unui nucleu al sistemului n jurul cruia acesta se dezvolt pas cu pas i se completeaz pe msura necesitilor aprute. Nu insistm asupra acestei soluii care nu constituie n sine o inovaie.
Proiectarea orientat obiect

Spre deosebire de SDLC, proiectarea orientat obiect, descris ca un proces unificat (Unified Process), se bazeaz pe o abordare obiect nc de la nceputul analizei. Un obiect poate fi abstractizarea unei entiti specifice utilizate n analiz sau componenta unei soluii de program n faza de realizare. Corespondena ntre acestea este mai evident dac limbajul utilizat este el nsui orientat obiect (exemplu, C++ sau Java).
Proiectarea orientat obiect ncepe cu definirea actorilor umani i a funciilor sistem ca obiecte care interacioneaz pentru a produce un anume rezultat distinct i important pentru proiect (artifact). Aa se construiesc cazurile de utilizare. Apoi, cazurile de utilizare se detaliaz n clase de obiecte de acelai fel, care conin date caracteristice i modurile lor de utilizare. n sfrit, comportamentul sistemului este descris prin diagrame de secven i de colaborare ntre aceste clase, care se finalizeaz prin realizarea tuturor funciilor sistemului proiectat.
Caracteristicile abordrii obiect

Obiectele sunt componente de program care efectueaz sarcini relativ limitate, ca de exemplu actualizarea unei liste sau trasarea unei linii. Tehnologia de proiectare i dezvoltare a obiectelor are unele trsturi care pot ajuta la nlturarea dificultilor de proiectare i ntreinere ale marilor sisteme software i anume 4: 1. Descrierea static i dinamic a cerinelor. Cuprinde mijloace de prevedere, nu numai cu privire la ceea ce va face programul dar i cum se presupune c va face acest lucru. 2. Descrierea i proiectarea static i dinamic. Prevede ci de specificare, nu numai a modului n care a fost alctuit programul dar, de asemenea, i cum interacionez obiectele ntre ele. 3. Modularitatea. Sistemele sunt adesea prea complicate pentru a putea fi abordate n detaliu; ele sunt descrise, de regul, prin blocuri funcionale mai mici, legate ntre ele printr-o ierarhie. Noi utilizm aceast ierarhie ca pe un prim instrument de conducere, meninnd, ntr-o oarecare msur independena blocurilor funcionale. 4. ncapsularea. Ascunde felul intern n care lucreaz obiectele fa de restul sistemului, permite divizarea strilor i definirea funciilor proprii fiecrui obiect. Se realizeaz astfel un management explicit al accesului la variabilele sistemului, acesta nefiind permis dect prin intermediul anumitor programe.
Observaie. Clasele de obiecte utilizeaz att modularitatea ct i ncapsularea. Privit din exterior, nu se vede cum lucreaz un obiect; el poate fi tratat ca o cutie neagr care rspunde la anumite ntrebri. Acest mod de lucru faciliteaz nelegerea i permite dezvoltatorului s-i concentreze atenia asupra modului de utilizare a obiectelor.
5. Motenirea. Permite mai multor tipuri de obiecte s reutilizeze proprieti i s defineasc noi funcionaliti. 6. Agregarea. Creeaz un obiect mare din agregarea unor obiecte mici, simple, permind manipularea strilor complexe. 7. Pachetele. ncapsuleaz obiecte n componente mai mari cu comportamente ascunse, permind abstractizri (ascunderea detaliilor) astfel nct programele complexe s poat fi conduse la diferite niveluri de detaliere.
7
Vezi [Gutu1] S.Guu, UML Limbaj de modelare unificat destinat managementului sistemelor complexe, n Sisteme informatice de management, Coordonatori L.Dumitracu i M.G.Petrescu, Editura Universitii din Ploieti, 2004, pp.37-68.
4
Principiile de baz ale abordrii obiect sunt: ncapsularea, motenirea i polimorfismul. ncapsularea Abordarea obiect a unui sistem ncepe cu definirea obiectelor aparinnd domeniului studiat. n cadrul unei categorii de obiecte de acelai fel (clas) se definesc, alturi de tipurile de date (atribute), toate aciunile de care obiectele aparinnd aceleiai clase sunt responsabile (operaii). O clas include toate tipurile de date i operaiile sale. Acesta este principiul ncapsulrii datelor i metodelor. De exemplu, pentru a proteja unele caracteristici importante ale unui obiect codul de acces al unui card, parola etc aceste atribute se declar interne, ele neputnd fi accesate dect prin intermediul unor metode ale clasei respective (necunoaterea acestor metode nu permite accesul). n acest fel, datele i metodele lor de acces formeaz un tot unitar de care ntraga clas este responsabil. Motenirea Cel de al doilea principiu de baz este motenirea, cu alte cuvinte transmiterea proprietilor unei clase (numit, n acest caz, superclas), ctre o aa zis clas derivat, care pe lng caracteristicile motenite poate avea i alte proprieti. n cadrul unei clase care servete la cutarea lucrrilor pe Internet, de exemplu, se pot defini unele principii generale, cum ar fi modul de avansare pe browser, accesul la paginile Web, avansarea nainte/napoi etc. n cadrul unor clase derivate care ar menine aceste principii de baz s-ar putea crea n plus ns diferite criterii de selecie: dup numele autorului, cuvinte cheie ale lucrrii, anul publicrii, editura etc care ar mri supleea i rapiditatea selectrii lucrrilor. Polimorfismul n sfrit, cel de al treilea principiu de baz al abordrii obiect este polimorfismul, adic pstrarea aceleiai denumiri pentru operaii asemntoare dar cu funciuni diferite, identificarea fcndu-se dup formatul de apel (forma i numrul parametrilor) dar i dup clasa creia i aparine. Aceasta permite simplificarea nelegerii logicii procedurilor i aciunilor, respectiv a programelor care le pun n aplicare. De exemplu, crearea unui obiect (instan) al unei clase se poate face, n general, n mai multe feluri: a) o generare standard, n care este suficient numele metodei, fr vreun parametru; b) o generare mai precis, n care s se indice numele instanei create, eventual termenul de valabilitate etc. n acest caz, dei metoda de generare poart acelai nume, formatul de apel va fi diferit, el neavnd parametri n cazul a), sau indicnd o serie de parametri n cazul b). Un alt caz: S presupunem c dispunem de o clas de baz care genereaz un punct de coordonate (x, y) ce va fi centru de simetrie i poziionare pentru o serie de figuri geometrice plane (cerc, ptrat) generate, la rndul lor, n clase derivate corespunztoare. Utilizarea aceluiai nume pentru metoda de generare, s spunem genereaza, nu va
crea confuzii, deoarece apelul din interiorul clasei Cerc va crea un cerc iar apelul din interiorul clasei Patrat va crea un ptrat. n acest fel se simplific modelul, utilizatorul tiind c pentru a genera ceva trebuie s tasteze generare, pentru a terge trebuie s formeze stergere etc, rezultatul fiind diferit n funcie de clasa din care apeleaz metoda.
Observaie. Marele avantaj al abordrii obiect este acela c, dac se alege ca mediu de programare tot un limbaj orientat obiect (de exemplu C++ sau Java), obiectele se pstraz i evolueaz n aceeai structur i interrelaionare, de la analiz pn la realizare.
UML standard industrial de modelare obiect

Necesitatea i obiectivele UML
Astzi, standardul industrial de modelare obiect este UML (Unified Modeling Language), dezvoltat sub directa responsabilitate a OMG (Object Management Group) un grup industrial interesat n unificarea metodologiei de proiectare i standardizarea tehnologiilor obiect, pentru a putea garanta interoperabilitatea sistemelor importante. OMG cuprinde actualmente peste 800 membri, printre care Sun, IBM, Microsoft etc., dar i mari ntreprinderi utilizatoare din toate sectoarele de activitate. n figura 1.1 este schematizat istoricul naterii i dezvoltrii UML. Prinii acestui limbaj sunt considerai a fi Grady Booch, James Rumbaugh i Ivar Jacobson datorit unor prime lucrri n acest domeniu Object Management Technology (OMT) i Object Oriented System Engineering (OOSE) - nc din anul 1994. n anul 1995 se consemneaz o prim tentativ de unificare a conceptelor ncercat de Booch i Rumbaugh, la care se altur i Jacobson n anul 1996. Lucrarea comun este naintat OMG n ianuarie 1997 cnd apare i prima versiune UML 1.0. adoptat la sfritul acestui an, dup anumite completri, sub numele UML 1.1. Eforturi susinute de standardizare din parte a OMG duc la apariia unor versiuni din ce n ce mai complete, aplicabile n industrie: 1.3 n anul 1999 i UML 1.4 n septembrie 2001 5. Astzi se aplic pe scar larg versiunea 2.0 i, de
9
A se vedea [RRRT] Rational Rose RealTime for Windows, pachet de programe comercializat de IBM, http:/www. downseek.com/download/19186.asp
5
curnd, i-au fcut apariia versiunile 3.0, 3.1 i 3.2 n cadrul unor pachete de programe promovate de firmele specializate n grafic pe calculator 6.
Figura 1.1 Istoricul UML
2004 2003 09/2001: vers.1.4 06/1999: vers.1.3 11/1997: adoptarea de ctre OMG 09/1997: vers.1.1 01/1997: naintarea la OMG 10/1996:
UML 3.0 UML 2.0 UML 1.4 UML 1.3 UML 1.1 UML 1.0
Industrializare Standardizare OMG
Partenerii UML UML 0.91 UML 0.9 Unificarea Metodelor
06/1996: 10/1995: 10/1994:
Metoda unificat 0.8 Booch93+OMT-2
G.Booch Booch-91
J.Rumbaugh OMT-1
I.Jacobson OOSE
10
Conform UML, un concept derivat din cerinele utilizatorului n conformitate cu cazurile lui de utilizare este proiectat mai departe n realizarea modelului i n
A se vedea [VP3.2UG] Visual Paradigm for UML 3.2 Users Guide Copyright 1999-2004 by Visual Paradigm, http:/www.apache.org Apache Software Foundation.
6
programare. Invers, plecnd de la program, putem descoperi crei necesiti i corespunde acesta i, n consecin, care este ideea care a stat la baza proiectului (reverse engineering).
Versiunile UML 7
Din anul 1997 pn n prezent, UML a cunoscut numeroase modificri, acestea fiind concretizate n versiuni mai mult sau mai puin cunoscute publicului. Este de notat faptul c principiile UML au rmas, n general, neschimbate, versiunile UML opernd n special n domeniul formalismelor utilizate (notaii, simboluri, convenii).
De la UML 1.0 la UML 1.1

ntre versiunile UML 1.0, aprut n ianuarie 1997 i UML 1.1 propus n luna septembrie a aceluiai an, nu s-au semnalat deosebiri importante. Rolul de ngheare (frozen) al asocierilor de tip compunere a fost desfiinat. El se aplic, de la caz la caz, anumitor asocieri ale claselor i atributelor lor. Returul n diagramele de secven a fost stabilit s se reprezinte cu linie ntrerupt.
De la UML 1.2 (i 1.1) la UML 1.3

UML 1.2 a aprut n anul 1998 iar UML 1.3 n anul 1999. Pentru aceast versiune s-au semnalat unele modificri importante.
Cazurile de utilizare
Dac versiunea UML 1.1 recunotea dou tipuri de relaii ntre cazurile de utilizare, use i extends, ambele sub form de stereotipuri, versiunea UML 1.3 nlocuiete use prin include, introduce generalizarea i definete extensia ca pe un stereotip de dependen form mai controlat dect relaia de generalizare.
Diagramele de activiti
Pentru a nota o condiie, se poate utiliza un romb pentru a nota att o ramificaie ct i o fuziune (condiia se menioneaz n parantez).
11
[Fowler2] Martin Fowler - UML 2.0 CampusPress, 2004, pp.181-189 (trad.l.engl. UML Distilled Third Edition, Addison Wesley, 2003).
7
Bara de sincronizare poate fi sau o ramificaie sau o jonciune. Nu se pot aduga condiii arbitrare jonciunilor. Oricrei ramificaii trebuie s-i corespund o jonciune care s reuneasc threads create prin acea ramificaie. Se pot imbrica ramificaiile i jonciunile i se pot elimina din diagram ramificaii i jonciuni atunci cnd threads pleac direct de la o ramificaie la alta sau de la o jonciune la alta. Jonciunile nu sunt activate dect atunci cnd toate threads care intr sunt terminate. Dar putei avea o condiie asupra unui thread care pleac dintr-o ramificaie. Dac aceast condiie este fals, se consider c thread este terminat pentru nevoile jonciunii. S-a considerat c urmtoarele versiuni ale UML ar putea modifica total diagramele de activiti (vezi UML 2.0).

Cea mai important schimbare adus de UML 1.4 const n adugarea profilurilor, ceea ce permite colectarea unui grup de extensii ntr-un ansamblu coerent. Documentaia UML conine dou exemple de profiluri. Totodat, formalismul definirii de stereotipuri a crescut i elementele modelului au putut avea mai multe stereotipuri, n timp ce n UML 1.3 exista unul singur. A fost adugat artefact-ul manifestare fizic a unei componente, s-a lucrat asupra vizibilitii pachetelor Java n metamodele i asupra marcrii asincronismelor prin sgei n diagramele de secven.

Principala modificare a fost adugarea unei semantici de aciune, etap necesar pentru a face din UML un limbaj de programare. Principalele caracteristici ale UML 2.0 Una din schimbrile cele mai evidente privete tipurile de diagrame. Diagramele de obiecte i diagramele de pachete devin diagrame oficiale. Diagramele de colaborare devin diagrame de comunicare. UML 2.0 introduce, de asemenea, noi tipuri de diagrame: vedere de ansamblu a interaciunilor, timing i structuri compozite.
Referitor la diagramele de clase: concepte eseniale

Atributele i asocierile unidirecionale devin dou notaii esenial diferite pentru a reprezenta conceptul sub-adiacent de proprietate. Multiplicitile discontinui (exemplu [2,4]) au fost abandonate. Nu mai exist proprietatea frozen. S-au adugat noi cuvinte cheie pentru dependene. Cuvintele cheie <<parameter>> i <<local>> nu se mai utilizeaz.
12
Diagramele de secven
Modificarea cea mai important este notaia cadrelor de interaciune, care permite gestionarea structurilor iterative, condiionale i a altor structuri de control ale comportamentului. Putei exprima aproape n ntregime algoritmii n diagramele de secven. Vechile marcaje de iteraii i notaiile lor au fost abandonate. Antetele de linii de via nu mai sunt instane, acestea fiind definite prin termenul participant. Diagramele de colaborare se numesc acum diagrame de comunicare.
Referitor la diagramele de clase: concepte avansate

Stereotipurile sunt definite de o manier mai strict. n consecin, exist cuvinte cheie pentru a defini expresiile ntre ghilimele, numai unele dintre acestea din urm fiind stereotipuri. n diagramele de obiecte, instanele sunt acum specificaii de instane. Clasele pot solicita interfee i le pot realiza. Clasificarea multipl utilizeaz ansambluri de generalizare pentru a regrupa generalizrile. Componentele nu mai sunt reprezentate printr-un simbol special. Obiectele active au linii duble verticale n loc de linii groase.
Diagramele de maini de stare

Dac UML 1 fcea distincia ntre aciuni (momentane) i activiti (continue), UML 2 numete cele dou activiti i utilizeaz acest termen n toate cazurile.
UML 1 trata diagramele de activiti ca pe un caz particular al diagramelor de stare. UML 2 a rupt legtura ntre acestea i a suprimat regulile de coresponden a ramificaiilor i jonciunilor pe care le instaurase UML 1. Au aprut noi notaii, printre care acelea de semnale temporale i de acceptare, parmetri, specificaii de jonciune, conectori, transformatori de fluxuri, greble de sub-diagrame, regiuni de expansiune i terminaii de fluxuri. UML 1 considera mai multe fluxuri de intrare ntr-o activitate ca pe o fuziune implicit, n timp ce UML 2 le trateaz ca pe o jonciune implicit. Pentru a evita confuziile, recomandm utilizarea fuziunilor i jonciunilor explicite n diagramele de activiti.
Tipuri de diagrame
UML este un limbaj esenialmente grafic, ce se definete n jurul mai multor categorii de diagrame, fiecare dintre acestea fiind dedicat reprezentrii unor
13
concepte particulare ale unui sistem informatic: prima categorie descrie serviciile funcionale, a doua privete structura static a sistemului iar cea de-a treia se refer la dinamica funcionrii sistemului.
Diagramele funcionale
Diagramele funcionale se bazeaz exclusiv pe cazurile de utilizare pentru specificarea cerinelor sistemului. Paradigma de reprezentare este ilustrat n figura 1.2 i are urmtoarea semnificaie: Actorul particip la Cazul de utilizare reprezentat n diagram. Att actorii ct i cazurile de utilizare trebuie s poarte denumiri unice, ntre cazurile de utilizare existnd i anumite relaii de care ne vom ocupa ulterior. Cazurile de utilizare arat ce anume trebuie proiectat, fr a da vreo indicaie cum s se fac acest lucru.
Figura 1.2 Diagrama UML. Cazuri de utilizare
Actor
Caz de utilizare
Capitolul 2 se ocup de specificarea cerinelor conform cazurilor de utilizare i construirea diagramelor cazuri de utilizare.
Diagramele statice (sau structurale)

Diagramele statice, numite i diagrame structurale, arat legturile ntre diferitele elemente de structur ale modelului i se refer la: diagramele de clase; diagramele de obiecte; diagramele de pachete; diagramele de structuri compozite; diagramele de componen; diagramele de desfurare.
14
Diagramele de clase
Diagramele de clase, a cror paradigm de reprezentare este ilustrat n figura 1.3, constituie punctul central al dezvoltrii obiect. n figura menionat, clasa B caracterizat prin atributele atribut2 i atribut3 i operaiile operaie2 i operaie3 este asociat clasei A caracterizat prin atribut1 i operaie1 printr-o relaie de agregare. Cu alte cuvinte, un numr neprecizat de instane ale clasei B (notat cu 0..*) intr n compunerea unei instane aparinnd clasei A. Pe de alt parte, clasa A este legat printr-o relaie de generalizare /particularizare de sub-clasa A1 care i motenete proprietile (atribut1 i operaie1) avnd n plus operaie4.
Pentru analiz, diagrama de clase este util deoarece descrie structura entitilor manipulate de utilizator. n realizarea modelului, cu o diagram de clase se reprezint de obicei structura programelor orientate obiect sau, mai precis, modulele limbajului de dezvoltare.
Figura 1.3 Diagrama de clase UML
Clasa A atribut1 operaie1() 1 0..*
Clasa B atribut2 atribut3 operaie2() operaie3()
Sub-clasa A1 operaie4()
Pe parcursul acestei lucrri, clasele au fost abordate de la simplu la complex. Astfel, capitolul 3 se ocup cu construirea claselor conceptuale i a relaiilor dintre aceste clase. Capitolul 6 se ocup de clasele rezultate din analiz i arat cum se construiete diagrama acestor clase (DCP Diagrama Claselor Participante la analiz). n sfrit, capitolul 9 se ocup de proiectarea specificaiilor de interfa
15
software i arat cum se construiesc diagramele claselor detaliate.
Diagramele de obiecte
O diagram de obiecte este o fotografie a obiectelor unui sistem la un moment dat. Ele reprezint instane ale claselor (nu clase), de aceea se mai numesc i diagrame de instane. Un exemplu al acestui tip de diagram este prezentat n figura 1.4.
Figura 1.4 Diagrama de obiecte UML
centru : ntreprindere localitate = Bucureti copil printe copil filiala2: ntreprindere localitate = Constana copil Ionescu: Angajat localitate = Braov
filiala1 : ntreprindere localitate = Braov printe copil
Georgescu : Angajat localitate = Braov
16
Diagrama reprezint o ierarhie a unor obiecte aparinnd unor clase. Numele clasei (obligatoriu) este menionat dup semnul : (obligatoriu). Numele obiectului (opional) este menionat naintea semnului :. Din diagram se observ c: 1. Filialele sunt tot ntreprinderi, prin urmare motenesc proprietile acestei clase, singura diferen fiind localitatea n care funcioneaz; 2. Angajaii ntreprinderii motenesc i ei proprietile ntreprinderii care i remunereaz, indiferent de localitate. Angajaii posed caracteristici proprii care nu sunt evideniate n diagram. Elementele unei diagrame de obiecte sunt specificaii de instane ale claselor i se utilizeaz n cazurile complexe, acolo unde diagramele de clas sunt greu de neles i pot da natere la interpretri diferite. Obiectele intervin n cadrul: diagramelor de secven (vezi capitolul 5 i
capitolul 7), diagramelor de colaborare (vezi capitolul 7), diagramelor de stare (vezi capitolul 8) i diagramelor de activiti (vezi capitolul 8).
Diagramele de pachete
Clasele reprezint structura de baz a unui sistem orientat obiect. Totui, atunci cnd avem de-a face cu sisteme mari, cu sute de clase, acestea devin dificil de neles i necesit gruparea elementelor UML n pachete. Orice construcie UML (cazuri de utilizare, clase, obiecte) poate fi grupat n uniti de nivel mai nalt sub form de pachete. ntr-un model UML, fiecare clas aparine unui singur pachet i poart un nume distinct n cadrul pachetului. Pachetele pot fi, n acelai timp, membre ale altor pachete, ceea ce conduce la o structur ierarhizat de pachete i clase. Un pachet poate conine, totodat, sub-pachete i clase independente. n UML, numele pachetului este urmat de semnul :: care l desparte de numele sub-pachetului sau de numele clasei componente. n exemplul din figura 1_5 este reprezentat pachetul java din care face parte sub-pachetul util care conine, la rndul su, clasa Date.
Figura 1.5 Diagrama de pachete UML
java util
Date
(de java::util) 8.
Ceea ce este reprezentat n figura 1.5 va putea fi notat java::util::Date sau Date Diagramele de pachete sunt tratate n capitolul 2 i capitolul 9.
17
Aceast notaie a fost introdus de firma Rational Rose i nu face parte din standardul UML.
8
Diagramele de structuri compozite

Una din noile caracteristici ale UML 2.0 const n posibilitatea de a descompune ierarhic o clas ntr-o structur intern. Aceasta permite subdivizarea unui obiect complex n diferitele sale pri componente. n figura 1.6, de exemplu, este reprezentat clasa Telecomand mpreun cu interfeele sale.
Figura 1.6 Diagrama de structuri composite UML (dup Jim Rumbaugh) a). reprezentarea global b). reprezentarea compozit
Telecomand
<<interfee realizate>> comanda TV om-main comanda TV aplicaii <<interfee cerute>> reglaj afiare flux de imagini
comanda TV om-main
Telecomand :Controlor :Generator

Comanda TV aplicaii reglaj flux de imagini
b).
afiare
a).
Din figura 1.6 a)., nu rezult dect c aceast clas are dou feluri de interfee: realizate i cerute, precum i denumirea acestora. Din figura 1.6 b)., aflm c aceast clas se descompune, de fapt, n dou pri: controlor i generator iar interfeele sunt cuplate astfel: comanda TV om-main la partea numit controlor, iar comanda TV aplicaii, mpreun cu afiarea, reglajul i fluxul de imagini, la partea numit generator.
Observaii privind notaiile: 1. Pentru a arta c o parte implementeaz o interfa, am desenat un conector sub form de cerc i o sgeat cu linie ntrerupt care sosete n partea respectiv. 2. Pentru a arta c o parte necesit o interfa, am desenat un cuplor sub form de semicerc i o sgeat cu linie ntrerupt care pleac din partea respectiv.
18
Structurile compozite sunt noi n UML 2.0 i, datorit acestei nouti, este prematur s se prevad pn la ce punct se vor dovedi ele eficace n practic.
Diagramele de componen
Diagramele de componen, a cror paradigm de reprezentare este dat n figura 1.7, constituie concepte de configurare a programelor n pachete de programe, n fiiere surs sau n biblioteci. Aceste concepte arat cum se leag ntre ele fiierele surs, pachetele de programe i bibliotecile, n cadrul sistemului informatic proiectat. Astfel, n figura menionat sunt reprezentate pachetul de programe de tip <<Applet>>, care cuprinde toate programele de interfa ommain (IOM) i care comunic cu pachetul de programe de tip <<Baza de date>> numit Clieni. Cele dou pachete de programe pot fi amplasate pe maini diferite sau n biblioteci diferite n cadrul sistemului informatic.
Figura 1.7 Diagrama de componen UML
<<Applet>> IOM <<Baza de date>> Clieni
Diagramele de componen sunt utilizate n cadrul capitolului 11.
Diagramele de desfurare
Diagramele de desfurare, a cror paradigm de reprezentare este ilustrat n figura 1.8, corespund structurii de reea informatic ce preia sistemul de programe i modul n care sunt instalate componentele de reea. Astfel, din figura 1.8 rezult c sistemul local este constituit din serverul central, la care sunt legate un server de nlnuire i un server Web.
19
Figura 1.8 Diagrama de desfurare UML
Server central Server Web
Server de nlnuire
Diagramele de desfurare sunt utilizate n cadrul capitolului 11.
Diagramele dinamice (sau comportamentale)

Diagramele dinamice, numite i diagrame comportamentale, arat cum interacioneaz ntre ele diferitele elemente ale modelului. Diagramele dinamice sunt alctuite din: diagramele de activiti; diagramele de stare; diagramele de secven; diagramele de colaborare; diagramele de vedere de ansamblu a interaciunilor; diagramele de timing.
Diagramele de activiti, a cror paradigm de reprezentare este ilustrat n figura 1.9, reprezint regulile de nlnuire ale activitilor n cadrul sistemului (de exemplu, navigarea ntr-un site Web). Activitile sunt reprezentate prin dreptunghiuri ovalizate iar trecerea de la o activitate la alta prin sgei, care se ntlnesc n noduri de stare marcate prin linii verticale. Ansamblul activitilor are un punct de intrare i un punct de ieire, marcate ca n figur.
20
Figura 1.9 Diagrama de activiti UML
Activ.2 Activ.1 Activ.3
Diagramele de activiti sunt tratate n cadrul capitolelor 8 i 12.
Diagramele de stare
Diagramele de stare, a cror paradigm de reprezentare este ilustrat n figura 1.10, reprezint ciclul de via comun obiectelor unei aceleiai clase i permit completarea cunotinelor claselor, att n cadrul analizei ct i n cazul concepiei. Convenia de reprezentare este invers ca la diagramele de activiti, cu alte cuvinte strile sunt marcate prin dreptunghiuri cu coluri rotunjite iar drumul de la o stare la alta prin sgei reprezentnd aciuni specifice. Ca i la diagramele de activiti, exist mai multe ci prin care se poate ajunge de la o stare la alta. Alegerea unei ci sau a alteia depinde de condiiile n care se afl sistemul la momentul respectiv. n diagramele din figurile 1.9 i 1.10 nu sunt menionate condiiile de alegere a cilor prin care se poate ajunge de la o stare la alta.
Figura 1.10 Diagrama de stare UML
Stare1
Stare2
Stare3
21
Diagramele de stare sunt tratate n cadrul capitolelor 8 i 12.
Diagramele de secven, a cror paradigm de reprezentare este ilustrat n figura 1.11, servesc, n primul rnd, dezvoltrii de scenarii n cadrul analizei utilizrii sistemului. n diagramele de secven mesajele sunt reprezentate orizontal, pe o ax a timpului de sus n jos, de attea ori de cte ori apar.
Figura 1.11 Diagrama de secven UML
:Clasa A :Actor m1 m2
:Clasa B
Diagramele de secven sunt tratate n capitolele 5 i 7, fiind apoi reluate n cadrul capitolului 12.
Diagramele de colaborare 9
Diagramele de colaborare, a cror paradigm de reprezentare este ilustrat n figura 1.12, servesc aceluiai scop ca i diagramele de secven. n diagramele de colaborare exist o singur cale, care unete dou elemente (clase, actori), mesajele care circul pe aceast cale mpreun cu sensul lor fiind marcate pe marginea cii cu sgei. De obicei, diagramele de colaborare se construiesc pe baza diagramelor de secven i ilustreaz schimburile de mesaje ntre obiecte n
Am menionat c UML 2.0 numete acest tip de element diagram de comunicare. Noi vom continua s pstrm, n cadrul acestei lucrri, termenul de diagram de colaborare, care ni se pare mai sugestiv, pentru a pstra corespondena cu unele lucrri mai vechi n domeniul limbajului UML.
9
22
cazul anumitor funcionri particulare ale sistemului. Att diagramele de secven ct i diagramele de colaborare fac parte din subclasa diagramelor de interaciune UML.
Figura 1.12 Diagrama de colaborare UML
1:m1 :Clasa A 4: :Actor 3: :Clasa B 2:m2
Diagramele de colaborare sunt tratate n capitolul 7, fiind apoi reluate n cadrul capitolul 12.
Diagramele de vedere de ansamblu a interaciunilor

Diagramele de vedere de ansamblu a interaciunilor (ineraction overview diagrams) sunt o combinaie ntre diagramele de activiti i diagramele de
secven. Ele se pot considera fie diagrame de activiti n care activitile sunt nlocuite prin mici diagrame de secven, fie diagrame de secven divizate, notaiile avnd menirea s uureze citirea acestor diagrame. n figura 1.13 este prezentat un exemplu simplu al acestui tip de diagrame. Se dorete producerea i formatarea unei liste recapitulative a comenzilor. Dac clientul este extern, obinem informaii ntr-un formular XML. Dac clientul este intern, l obinem dintr-o baz de date. Cele dou diagrame de secven ne arat cele dou posibiliti. Odat obinute datele, putem emite lista recapitulativ a comenzilor.
Acesta este un nou tip de diagram UML 2.0 i este nc prematur de a emite o idee referitoare la modul n care va fi el utilizat n practic.
______________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________
23
Figura 1.13 Diagrama de vedere de ansamblu a interaciunilor
[date externe] :Client :AnalizorXml ncarc getNume analizeaz
[date interne] :Client :BazDeDate
selecioneaz dup clieni i comenzi new
getCom new :ComReper toriuCzi new
:Repertoriu Comenzi
List Repertoriu Comenzi
Diagramele de timing
Diagramele de timing reprezint o alt form de diagrame de interaciune, n care accentul este pus pe constrngerile de timp, fie pentru un obiect, fie pentru un grup de obiecte. S lum, pentru exemplificare, scenariul de funcionare al unei cafetiere electrice. Aceasta se compune, n principal, din dou automate: cel al pompei de evacuare al preparatului de cafea i cel al plcii nclzitoare. S presupunem c ntre activarea pompei i cea a plcii nclzitoare trebuie s treac un interval de minimum 10 secunde. Atunci cnd rezervorul se golete, pompa se oprete, ns placa poate continua s funcioneze nc 15 minute 10.
24
10
Vezi [Fowler2] UML 2.0 CampusPress, 2004, pp.181-189 (trad.l.engl. UML Distilled Third Edition, Addison Wesley, 2003), pp.171-172
Figura 1.14 Diagrama de timing
Pompa Placa nclzitoare
n funciune Oprit n funciune Oprit {>10 s}
Rezervor golit timp {<15 min}
n figura 1.14 este reprezentat diagrama de timing pentru acest caz. Funcionarea celor dou pri principale, pompa i placa nclzitoare, este reprezentat pe aceeai diagram a timpului. Modificrile de stare sunt semnalate prin schimbri de nivel ale liniilor continue care urmresc procesul. Liniile ntrerupte verticale sunt opionale i ajut la precizarea momentului n care are loc evenimentul. Diagramele de timing reprezint, de asemenea, o inovaie adus de UML 2.0. Ele sunt utile pentru reprezentarea restriciilor temporale ntre schimbrile de stare ale diferitelor obiecte.
Clasificarea diagramelor UML

n ncheiere, v prezentm n figura 1.15 o schem de clasificare a diagramelor UML 2.0 care utilizeaz simbolul de generalizare/ particularizare promovat de acest standard 11. Spre deosebire de aceast clasificare, care plaseaz diagramele cazuri de utilizare n clasa diagramelor comportamentale, noi am preferat s ridicm acest tip de diagrame la un nivel superior, deoarece prezint att caracteristici de grupare structural ct i proprieti comportamentale. Printre caracteristicile structurale amintim: un caz de utilizare concentreaz n jurul su tot ce este semnificativ dintro aplicaie i care produce un rezultat semnificativ pentru un anumit
25
11
Vezi [Fowler2] UML 2.0 CampusPress, 2004, pp.181-189 (trad.l.engl. UML Distilled Third Edition, Addison Wesley, 2003), p.22
actor, adic obiecte, clase i proprietile acestora care prin interaciune conduc la rezultatul vizat. gruparea claselor i obiectelor implicate ntr-un caz de utilizare seamn foarte mult cu aceea de pachet de nivel superior, dar semnificaia sa este diferit, fiind legat esenial de comportament i scopul final al acestuia. Caracteristicile comportamentale rmn totui acelea eseniale i rezult din faptul c la baza separrii elementelor proiectului st comportamentul care conduce la realizarea artefact-ului pentru actorul n cauz.
Figura 1.15 Diagrama UML. Cazuri de utilizare
Diagrama de clase Diagrama de structuri compozite Diagrama de obiecte Diagrama de cazuri de utilizare Diagrame comportamentale Diagrama de activiti Diagrama de stare Diagrame de interaciune
Diagrama de componen Diagrama de desfurare Diagrama de pachete Diagrama de secven Diagrama de colaborare Diagrama vedere de ansamblu a interaciunilor Diagrama de timing
Diagrame de structur
Diagrame
26
Specificarea cerinelor conform cazurilor de utilizare
n acest capitol: Cazurile de utilizare Diagramele cazuri de utilizare i elementele lor
Primul pas n dezvoltarea unui proiect de sistem informatic este nelegerea clar a problemei. n acest scop, orice analiz ncepe cu construirea cazurilor de utilizare, care descriu modul n care va fi utilizat sistemul. Pentru a facilita aceste descrieri, dezvoltatorii UML au inclus diagramele caz de utilizare n specificaia limbajului. Fiecare caz de utilizare trebuie s aib un nume, un numr i o descriere. Un caz de utilizare trebuie s respecte o anumit form de descriere. a. Acest caz ncepe atunci cnd .... b. Sistemul rspunde prin ... (secven de interaciuni) ... c. Acest caz se termin atunci cnd ...
Exemplu:
Iat cum descriem cazul de utilizare: Trasarea unei linii ntr-un program de desenare. a. Acest caz ncepe atunci cnd utilizatorul clickeaz pe icon-ul linie n bara de menu. b. Sistemul rspunde prin schimbarea cursorului cu o cruciuli. Atunci cnd utilizatorul execut click pe desen i trage cursorul, sistemul traseaz o linie.
27
c. Acest caz se termin atunci cnd utilizatorul ridic degetul de pe butonul stng al mouse-ului. Linia rmne iar cruciulia dispare. Un caz de utilizare reprezint un ansamblu de secvene de aciuni realizate de sistem, care produc un rezultat observabil, interesant pentru un anume actor.
Diagramele cazuri de utilizare i elementele lor

Diagramele cazuri de utilizare sunt folosite pentru a stabili cerinele dinamice ale sistemului. Acest tip de diagrame poate fi ntlnit la dou niveluri: nivelul utilizatorului n care diagramele descriu cum interacioneaz utilizatorii cu sistemul, definind astfel cerinele sistemului; nivelul dezvoltatorului n care diagramele descriu cum interacioneaz componentele sistemului, definind astfel cerinele subsistemelor. Fia diagramei cazuri de utilizare este prezentat n figura 2.1. Elementele acesteia actorii, cazurile i relaiile dintre ele - vor fi detaliate n cele ce urmeaz (figura 2.2).
Figura 2.1 Fia diagramei UML cazuri de utilizare Fia diagramei Cazuri de utilizare UML Rol Diagrama caz de utilizare produce o prim viziune asupra Elemente Cnd se utilizeaz
structurii sistemului, un punct de plecare al proiectrii, o identificare a obiectelor i a diagramelor de secven. Actor extern, actor intern, actor subsistem, cazuri de utilizare, relaiile ntre cazurile de utilizare. La nceputul proiectrii, pentru definirea modului n care sistemul corespunde cerinelor utilizatorului. Diagramele caz de utilizare arat modul n care cazurile de utilizare se relaioneaz n cadrul sistemului.
Actorii
Un actor este un rol pe care utilizatorul l joac n raport cu sistemul. Actorii realizeaz cazurile de utilizare. Un singur actor poate realiza mai multe cazuri i, invers, un caz poate avea mai muli actori.
28
Tipurile de actori sunt prezentate n detaliu n figura 2.2. Exemplele se refer la studiul de caz e-commerce i la aplicaiile propuse spre rezolvare (vezi TEMA).
Figura 2.2 Tipurile de actori Element diagram UML

Actor extern
Reprezentare
Reprezint utilizatorul sau un sistem interacioneaz cu sistemul n cauz.
extern
care
Exemple:
Navigator Cutarea lucrrilor
Navigator Gestiunea coului
Navigator Efectuarea comenzii
Magazioner
ntreinerea fiierelor de magazie
Stabilirea programului eful seciei producie de fabricaie
Maistru
Distribuirea sarcinilor pe muncitori Selectarea listei de furnizori
29
Responsabil serviciu aprovizionare
Clientul
Actor intern
Efectuarea comenzii
Reprezint funcii ale personalului angajat
Exemple:
Efectuarea comenzii
Serviciul clieni
ntreinerea catalogului
Librar
ntreinerea site-ului
Webmaster Gestionarea magaziei de piese i subansambluri Gestionarea magaziei de materiale
Distribuirea sarcinilor pe muncitori

Actor subsistem
Denumire subsistem
30
Reprezint subsistemele automate de prelucrare a datelor privite, pentru moment, ca entiti globale.
Exemple:
Gestiunea stocurilor Librar ntreinerea catalogului Nouti
Gestiunea stocurilor Magazioner ntreinerea fielor de magazie
Lansarea comenzilor de fabricaie
Magazioner
Gestionarea fiei de magazie
Gestiunea stocurilor
Client
Efectuarea comenzii
Elaborarea comenzii de aprovizionat
Mai multe despre actori

Un actor reprezint un rol jucat de o entitate (utilizator uman, dispozitiv material sau alt sistem) extern cazului de utilizare studiat, care interacioneaz direct cu
31
acesta din urm. Un actor poate consulta sau modifica direct starea sistemului, emind sau primind mesaje purttoare de informaii. Actor este acela care beneficiaz de utilizarea sistemului. Este de dorit s se elimine, pe ct posibil, actorii fizici n favoarea celor logici. Aceasta ne permite s depim tehnologiile de interfa care risc s evolueze i s identificm actorii logici, susceptibili de a fi reutilizai. De exemplu, chiar dac aceeai persoan fizic poate juca succesiv rolurile de librar i Webmaster fa de site-ul Web, este vorba de doi actori diferii, dou profiluri distincte (vezi studiul de caz e-commerce).
Remarci: n cadrul capitolului 12 al acestei lucrri se arat un mod simplu de a genera un actor folosind pachetul de programe VP-UML (vezi figura 12.8). Acelai mod simplu de a crea un actor avem la dispoziie i atunci cnd lucrm cu pachetul de programe RRRT (vezi capitolul 11, paragraful 11.3 Adugarea unui caz de utilizare). n figura 11.8, care arat vederea de ansamblu a diagramei cazurilor de utilizare intitulat Use Case View /Main, n bara de instrumente a acesteia, situat pe latura stng a diagramei, se vede imaginea aceluiai instrument Actor (standard UML). Executarea unui click pe aceast imagine, urmat de mutarea mouse-ului n interiorul diagramei i efectuarea unui nou click genereaz un actor al crui nume poate fi imediat redefinit.
Cazurile de utilizare sunt prezentate n detaliu n figura 2.3. Exemplele se refer la studiul de caz e-commerce i la aplicaiile propuse spre rezolvare (vezi TEMA).
Figura 2.3 Cazurile de utilizare Element diagram UML

Caz de utilizare
Reprezentare
Cazul A Un ansamblu de secvene de aciuni. Cazurile de utilizare indic ce anume trebuie proiectat.
32
Exemple:
Cutarea lucrrilor
Gestionarea coului
Efectuarea comenzii
ntreinerea catalogului
ntreinerea informaiilor editoriale
ntreinerea sistemului
Consultarea unei comenzi n curs
Lansarea documentelor de fabricaie
Mai multe despre cazurile de utilizare

Fiecare caz de utilizare trebuie s aib un obiectiv n sine i s poat fi realizat independent de altele. Un caz de utilizare modeleaz un serviciu adus de sistem. El exprim interaciunile actorisistem i aduce o valoare adugat notabil respectivului actor. O eroare frecvent este aceea de a dori s se mearg prea n detaliu. Un caz de utilizare reprezint secvene de aciuni realizate de sistem, care reprezint n mod precis un obiectiv specific al actorului. Cazul de utilizare nu trebuie deci s se reduc la o singur secven i nici la o singur aciune.
Remarci: n cadrul capitolului 12 al acestei lucrri se arat un mod simplu de a genera un caz de utilizare folosind pachetul de programe VP-UML (vezi paragraful 12.3 punctul 3 i figura 12.9). Aceeai posibilitate de a crea un caz de utilizare exist i n cadrul pachetului de programe RRRT (vezi capitolul 11, paragraful 11.3 Adugarea unui caz de utilizare i diagrama din figura 11.9).
33
Relaii ntre cazurile de utilizare

Pentru a detalia diagrama cazurilor de utilizare, UML definete trei tipuri de relaii standard ntre cazurile de utilizare: Relaia de incluziune. Relaia de extensie. Relaia de generalizare /specializare. Relaiile ntre cazurile de utilizare sunt prezentate n detaliu n figura 2.4.
Figura 2.4 Relaii ntre cazurile de utilizare Element diagram UML

Incluziune
Reprezentare
A <<include>> B
Relaia de incluziune se folosete atunci cnd o secven de comportament este identic n mai multe cazuri de utilizare. Relaia de incluziune este formalizat prin cuvntul cheie <<include>>, n care cazul de utilizare de baz ncorporeaz explicit un altul, ntr-o manier obligatorie. Sgeata de la captul liniei ntrerupte arat ce include iar cazul de utilizare aflat la captul fr sgeat marcheaz cine include. Includerea se refer la ntreaga procedur B nglobat n A i executat obligatoriu odat cu A.
Exemplu:
<<include>> Analiza de risc Agent comercial <<include>> Expertiza Tarifare tranzacie C C <<extinde>> D D
Extensie
34
Relaia de extensie se folosete atunci cnd o secven de comportament poate continua secvena de baz. Relaia de extensie este formalizat prin cuvntul cheie <<extinde>>, n care cazul de utilizare de baz ncorporeaz implicit un altul, de manier opional. Sgeata de la captul liniei ntrerupte arat cine se extinde iar cazul de utilizare aflat la captul
fr sgeat marcheaz cu ce se extinde. Extinderea arat c n cazul D se poate trece, eventual, i la execuia procedurii C (neobligatoriu).
Exemple:
35
Generalizare /specializare
Relaia de generalizare se folosete atunci cnd una sau mai multe cazuri de utilizare descendente, derivate, motenesc datele i comportamentul unui caz de utilizare de baz, generalizant. Relaia de generalizare este formulat prin cuvntul cheie <<generalizeaz>>. Fiecare din cazurile derivate pot cuprinde comportamente specifice, care se adaug comportamentului motenit de la cazul generalizant. Generalizarea este opus specializrii. (Cazurile E i F reprezint specializri ale cazului G).
Exemple:
36
Remarc. Cazul de utilizare Gestiune clieni este un generalizant i cuprinde atribute comune precum numele clienilor sau adresa acestora, ca i metode specifice de generare i actualizare pentru atribute. Gestiune clieni poteniali i Gestiune clieni vechi reprezint specializri care cuprind n plus date precum forma de plat (card, cont bancar), creditul autorizat, termenul de valabilitate al acestuia, banca pltitoare etc, sau calificativ de bonitate pentru vechii clieni, n scopul simplificrii procedurii de cumprare. De asemenea, cazurile de utilizare specializate cuprind i metodele de generare i actualizare ale atributelor specifice menionate.
Mai multe despre relaii, n general

Asocierea este cea mai general relaie ntre elementele UML (clase, cazuri de
utilizare, actori etc) care descrie un ansamblu de legturi. Am vzut c actorul este legat de un caz de utilizare printr-o linie care arat c el este asociat acestui caz. Cazurile de utilizare sunt legate ntre ele prin asocieri specifice (incluziuni, extensii, generalizri) care au o simbolistic special i poart anumite semnificaii.
Remarci: n cadrul capitolului 12 al acestei lucrri se arat un mod simplu de a crea o asociere ntre un caz de utilizare i un actor, folosind pachetul de programe VPUML (vezi paragraful 12.3 punctul 4 i figura 12.9). Acelai mod simplu de a crea o asociere ntre un caz de utilizare i un actor exist i n cadrul pachetului de programe RRRT (vezi capitolul 11, paragraful 11.3 intitulat Adugarea unui caz de utilizare i diagrama din figura 11.9.) Se execut click pe sgeata ndoit Unidirectional Association din bara de instrumente a diagramei i se trage de la actor ctre cazul de utilizare respectiv. Extinderea sau generalizarea se execut, la ambele pachete de programe menionate mai sus, prin selectarea instrumentului respectiv din bara de instrumente a diagramei i tragerea de la cazul de utilizare extins sau generalizant ctre cellalt caz.
37
Obiecte, clase i relaiile dintre clase. Diagrama claselor conceptuale. Pachete de clase
n acest capitol: Analiza domeniului i identificarea obiectelor specifice Clasele i relaiile dintre clase. Diagrama claselor conceptuale Generalizarea conceptelor. Pachetele de clase
Analiza domeniului. Obiectele specifice i clasele lor. Relaiile ntre clase

Exprimarea general a nevoilor utilizatorului a condus la formalizarea cazurilor de utilizare, precum i a unor machete de interfa om-main IOM (vezi capitolele precedente). Aceste descrieri funcionale vor servi ca puncte de intrare pentru descrierea dinamic a scenariilor de execuie ale viitorului sistem. Concepia obiect se bazeaz ns, n principal, pe descrierea structural, static, a sistemului de realizat, sub form de ansambluri de clase de programe, eventual regrupate n pachete. Cele mai bune clase candidat sunt acelea care rezult dintr-o analiz a domeniului (numit adesea analiz specific), adic concepte manipulate de experii n domeniu.
38
Obiectele software i clasele

Obiectele sunt cele mai mici blocuri de cod n construcia unui program software. Ele au o funcionalitate limitat i reprezint primul nivel de abstractizare ntr-un program. Fiecare obiect are trei proprieti:
Starea cu alte cuvinte, structurile de date; Mediul reprezentat de metodele care realizeaz funcionalitatea; Identitatea o etichet unic. Variabilele care realizeaz starea obiectului sunt numite atribute. De exemplu, atributele unei linii desenate sunt: poziia, culoarea, stilul liniei .a. Starea obiectului este determinat de valoarea atributelor. Dac obiectele conin i i stpnesc strile atunci putem spune c ele sunt ncapsulate. ncapsularea uureaz repartiia sarcinilor i comunicaiile ntre obiecte. Obiectele reacionez la mediu, cu alte cuvinte fac ceva dac li se cere acest lucru. De exemplu, dac obiectul este o list, adaug un membru la list sau returneaz valoarea celui de-al n-lea membru al listei. Mediul acioneaz prin programe specifice metode (methods) apelate prin formate numite operaii. Exist cinci tipuri de astfel de metode, care: seteaz starea atributelor (sets); ntoarce starea atributelor (gets); modific starea proprie; cheam metode (invoking methods) ale altor obiecte sau servicii ale sistemului; se autocreaz i se autodistrug. Atributele se refer strict la obiectul respectiv. Respectnd aceast disciplin este relativ uor de descoperit ce face i cum interacioneaz o metod cu celelalte pri ale programului. Toate obiectele din program care mpart aceeai descriere (atribute i metode) se numesc instane ale aceleiai clase. De exemplu, multe linii create prin execuia unui program de desenare sunt instane ale clasei linie.
Clasa reprezint descrierea abstract a unui ansamblu de obiecte avnd aceleai caracteristici. Obiectul este o entitate cu limite bine definite, avnd o identitate i nglobnd o stare i un comportament. Un obiect este o instan a unei clase. Atributul reprezint un tip de informaie coninut ntr-o clas. Exemplu: viteza, cilindreea, numrul de nmatriculare, sunt atribute ale clasei Autoturism.
n programele orientate obiect se definesc mai nti clasele. Programul creeaz instane ale claselor, obiecte, pe msur ce are nevoie. Obiectele, ca instane ale claselor, au etichete unice, ceea ce ne permite trasarea strilor fiecrui obiect n parte. n UML, clasele sunt reprezentate prin diagrame de clase. Fiecare clas arat ca o cutie care conine trei arii: prima n care se specific numele clasei; a doua n care se noteaz atributele;
39
cea de-a treia care cuprinde operaiile, cu alte cuvinte formatul de apelare al metodelor. Acesta din urm pune n eviden: a) numele metodei; b) eventualii parametri de apel i forma acestora; c) forma datei ntoarse n program dup executarea metodei.
Operaia reprezint un element de comportament (un serviciu) coninut ntro clas. Observaie. Cea mai frecvent eroare la crearea unui model al domeniului este acela de a reprezenta ceva ca pe un atribut n loc de concept. Recomandm urmtorul criteriu de departajare: dac nu putem cere unei entiti dect valoarea sa, atunci acea entitate este un atribut; dac i putem pune mai multe ntrebri, atunci avem de-a face cu un concept care are la rndul su mai multe atribute i legturi cu alte obiecte. Exemplu
n figura 3.1 este prezentat un exemplu pentru clasa linie. Denumirea clasei (Line) apare n aria superioar. n aria de mijloc apar atributele Position i Color iar n aria inferioar sunt menionai civa operatori care enun metodele cu acelai nume: Set_position prin care se poziioneaz linia, set_color care face ca linia s aib culoarea dorit, get_color care ne furnizeaz culoarea unei linii de pe ecran, get_position prin care avem acces la poziia unei linii de pe ecran, Rotate prin care putem roti linia cu un anumit unghi. Semnul - arat c atributele nu pot fi accesate dect din interiorul clasei. n schimb, semnul + al operatorilor arat c ei pot fi accesai de oriunde, cu alte cuvinte sunt publici. n acest fel se protejeaz atributele unei clase de o eventual deteriorare a coninutului lor printr-o manipulare incorect.
Figura 3.1 Limbajul UML: specificaii de clas
40
Metodele pentru crearea unui obiect se numesc constructori.
Sintaxa pentru invocarea unui constructor i crearea unui obiect este, cel mai adesea, new. Atunci cnd este invocat new, programul aloc memoria pentru acel obiect. Pentru a distruge obiectul i a elibera memoria, este invocat un destructor cu operatorul delete.
Proiectarea claselor este independent de limbaj. La implementarea clasei trebuie s apar limbajul. Oricum, la acest nivel trebuie s se precizeze i tipul de variabil, obligatoriu pentru generarea codului.
Relaiile ntre clase. Generalizarea, asocierea, agregarea, compunerea

Clasele pot fi legate ntre ele prin moteniri. n UML, motenirea este numit adesea generalizare. Clasa A motenete clasa B dac fiecare metod i atribut din A se gsete, de asemenea, n specificarea lui B. Obiectele clasei A sunt un fel de obiecte ale clasei B, de aceea clasa B se mai numete i super-clas iar A sub-clas.
Super-clasa: este o clas general, cuprinznd un nucleu de caracteristici comune, legat la una sau mai multe alte clase specializate (sub-clase) printr-o relaie de generalizare. Sub-clasa motenete nucleul de caracteristici ale super-clasei, adugnd, eventual i alte atribute specifice.
S spunem c A specific obiecte pentru fereastra interfeei utilizator. Exist cteva feluri de tipuri de ferestre: pentru dialogul de tip pop-up, pentru introducere de date, pentru vizualizare de date .a., toate avnd o poziie i o dimensiune. Starea i metodele pentru mutare i dimensionare pot fi comune pentru fiecare tip de fereastr. Pe de alt parte, fiecare fel de fereastr are stri i metode unice. n proiectarea obiectului, se poate defini o clas numit Window (fereastr), urmnd ca fiecare fel de fereastr s moteneasc aceast clas de baz. Fiecare clas derivat reutilizeaz rutinele de mutare i dimensionare a ferestrei. n figura 3.2 este artat un exemplu de utilizare a UML pentru a specifica motenirea ntr-o diagram de clas. Clasele Pop_Up i Entry_Window motenesc clasa Window 12.
41
12 Vezi [Gutu1] S.Guu, UML Limbaj de modelare unificat destinat managementului sistemelor complexe, n Sisteme informatice de management, Coordonatori L.Dumitracu i M.G.Petrescu, Editura Universitii din Ploieti, 2004, pag.49.
Figura 3.2 Limbajul UML: specificaie de clas
Obiectele trebuie s interacioneze ntr-un mod util. Modul fundamental de interacionare al obiectelor este acela ca o metod a unui obiect s invoce metode din alt obiect. n particular, dac dorim ca metodele din clasa B s invoce metodele din clasa A, producem o asociere unidirecional, de la A spre B, ntre aceste clase. Notaia UML pentru acest tip de asociere este artat n figura 3.3 (1). Este posibil i o asociere bidirecional, aa cum se arat n exemplul din figura 3.3 (2) pentru clasele A i C, n sensul c orice metod din clasa A poate fi invocat din C i reciproc. Specificnd care tip de obiect interacionez cu alte obiecte, meninem controlul asupra proiectului i asupra codului generat.
Asocierea este o relaie semantic durabil ntre dou clase. Exemplu: o persoan poate avea un autoturism.
42
Asocierea poate fi nominalizat. n exemplul nostru putem spune c persoana are un autoturism. Observaie. Asocierea ntre concepte este implicit bidirecional (se nelege, implicit, c un automobil se afl n posesia unei persoane). La cele dou capete ale unei asocieri se pot face indicaii de multiplicitate. Ele specific, sub forma unui interval, numrul de obiecte care pot participa la o relaie cu un obiect din alt clas, n cadrul unei asocieri.
Exemplu: n figura 3.3, asocierea 2 arat c putem avea sau nu un obiect din clasa A (0..1) asociat mai multor obiecte din clasa C (0..*). Alte notaii uzuale pentru indicatorul de multiplicitate: (n) - un numr fix de n obiecte se pot afla la un moment dat n relaie de asociere (n poate fi i 1); (1..*) - cel puin un obiect se poate afla la un moment dat n relaie de asociere. Figura 3.3 Limbajul UML: specificarea tipurilor de asociere
Adesea este util s avem atribute ale unei clase care s conin o alt clas. De exemplu, putei avea o clas care a devenit mare i incomod de manevrat. n acest caz, ai putea declara aceast clas ca fiind fcut din mai multe subclase. Starea acestor subclase poate fi stpnit separat, reducnd astfel complexitatea problemei. Cnd o clas este un tip al atributelor unei alte clase, spunem c cele dou clase sunt legate prin agregare. n UML, agregarea este un fel de asociere a claselor. Aceasta este artat n figura 3.4: obiectele clasei A (angajat) sunt asociate (1) cu obiecte ale clasei B (echip) i (2) cu un obiect al clasei C (ntreprindere), numai c rolul lor n cadrul acestor asocieri este diferit.
Figura 3.4 Limbajul UML: specificarea agregrii i compunerii
43
A se nota c agregarea este numai unidirecional. Obiectele clasei A pot aparine mai multor obiecte ale clasei de tip B (de exemplu, un angajat al unei ntreprinderi care poate lucra n mai multe echipe de proiectare), n timp ce clasa C dispune de un singur obiect (n exemplul nostru ntreprinderea), astfel nct dispariia acestuia provoac de fapt dispariia clasei A. Aceasta creaz o difereniere care face ca cel de-al doilea tip de agregare s fie mai puternic i s poarte o denumire special: compunere. Compunerea este marcat n diagram cu un romb plin n timp ce agregarea este figurat cu un romb vid.
Agregarea, marcat cu un romb vid, este un caz particular de asociere nesimetric cu alte cuvinte, un obiect dintr-o clas este asociat mai multor obiecte din alt clas. Agregarea exprim o relaie de a conine, este compus din i din acest motiv n-are nevoie s fie nominalizat. O compunere este o agregare mai puternic ce implic faptul c: obiectele dintr-o clas asociate unui obiect din alt clas compun de fapt acel obiect, cu alte cuvinte toate sunt la fel de importante i determinante pentru obiectul pe care l compun; durata de via a obiectului compus este aceeai cu a obiectelor care l compun, cu alte cuvinte dispariia obiectului compus antreneaz nemijlocit dispariia tuturor componentelor sale.
Diagrama claselor conceptuale i elementele sale

pentru a stabili clasele Diagramele claselor conceptuale sunt folosite conceptuale ale sistemului i relaiile dintre ele. Fia diagramei claselor conceptuale este prezentat n figura 3.5. Elementele acesteia clasele i relaiile dintre ele vor fi detaliate n cele ce urmeaz (figura 3.6).
Figura 3.5 Fia diagramei UML clase conceptuale Fia diagramei UML Clase conceptuale Diagrama claselor conceptuale produce o prim viziune Rol Elemente Cnd se utilizeaz
44
asupra structurii de clase a sistemului, o identificare a obiectelor conceptuale i a relaiilor dintre acestea. Clas, atribut, operaie, asociere, multiplicitate, compunere, agregare, generalizare. n general, clasele constituie coloana vertebral a tuturor abordrilor obiect i se folosesc pe tot parcursul proiectrii. La nceputul proiectrii, pentru definirea conceptelor
sistemului i a relaiilor dintre acestea se utilizeaz clasele conceptuale de regul fr operaii, eventual cu cteva atribute eseniale nedetaliate. Diagramele claselor conceptuale arat modul n care cazurile de utilizare se descompun n clase, care se relaioneaz n cadrul sistemului.
Clase
Informaiile succinte despre clase i caracteristicile lor sunt prezentate n detaliu n figura 3.6. Exemplele se refer la studiul de caz e-commerce precum i la alte cazuri explicate pe parcurs.
Figura 3.6 Informaii despre clase Element diagram UML

Clas
Reprezentare
Numele clasei atribute
operaii
Clasa reprezint descrierea abstract a unui ansamblu de obiecte avnd aceleai caracteristici. Caracteristicile se mpart n: caracteristici statice numite atribute i caracteristici dinamice numite metode. Atributele descriu nsuiri ale obiectelor. Metodele descriu comportamentul obiectelor, cu ajutorul limbajelor de programare. Formatul de apel al unei metode poart numele de operaie. O clas se reprezint ca o cutie care conine trei compartimente: primul, care specific numele clasei; al doilea, n care se noteaz atributele; al treilea, care cuprinde operaiile. Dintre acestea, numai primul este obligatoriu. Remarci: Clasele conceptuale conin, de regul, numai numele clasei i, eventual, cteva atribute de baz, mai rar numele unor operaii (fr formatul de apel sau cu format de apel incomplet). Totalitatea claselor conceptuale i a legturilor dintre ele formeaz modelul conceptual. Pe msur ce proiectul avanseaz, clasele se contureaz mai
45
bine i se mbogesc cu noi atribute i operaii. n faza preliminar implementrii (faza specificaiilor de 13 interfa ), clasele, dei nu sunt nc legate de un anumit software, conin maximum de informaii. Ansamblul lor formeaz modelul specificailor de interfa. n sfrit, n faza de implementare, clasele poart din plin pecetea pachetului de programe prin care se realizeaz efectiv proiectul. Ansamblul acestora definete modelul de implementare al proiectului.
Exemple
Remarc. Exemplul de mai sus conine o clas conceptual cu cele trei zone evideniate. Sunt enunate principalele atribute: titlu, subtitlu, ISBN, limba, dataApariiei i pre. Atributul subtitlu poate uneori s lipseasc, ceea ce este marcat cu [0..1]. Operaia carte() reprezint constructorul (fr parametri) al unui obiect Carte, getCarte() servete la obinerea unui obiect Carte din afara clasei Carte iar setCarte() are drept scop s actualizeze, din exteriorul clasei Carte, o carte cu valori pentru: titlu, subtitlu etc.
46
13
Remarci: n acest exemplu, atributele figurate sunt: data, modPlata etc.
Vezi [Fowler&Scott], pp.68-70.
Operaia comanda(Client, Co) reprezint constructorul (cu parametrii Client i Co care constituie legturi pointeri sau referine, nu se precizeaz deoarece este o clas conceptual la clasele Client, respectiv Co. n rest, aceleai observaii ca n exemplul precedent. Remarc. Vezi Capitolul 12 (VP-UML) figura 12.17 (Clasa Carte, cu atributele sale, generat cu VP-UML), figura 12.18 (Diagrama de clase cu entitile Carte, LinieCo i Co) generat cu VP-UML.
Relaii ntre clase

Informaii succinte despre tipurile de relaii ntre clase i caracteristicile acestora sunt prezentate n detaliu n figura 3.7. Exemplele se refer la studiul de caz ecommerce precum i la alte cazuri explicate pe parcurs.
Figura 3.7 Informaii despre relaiile ntre clase Element diagram UML
Asocierea
Reprezentare
Asocierile reprezint legturi ntre instanele claselor. Din punct de vedere conceptual, asocierile reprezint relaii conceptuale ntre clase. Fiecare asociere are dou extremiti (a, b), care poart numele de roluri, fiecare extremitate fiind legat la una din clasele de asociere. n absena unei denumiri, numele rolului este identic cu numele clasei la care este legat. Fiecrui rol i se poate asocia o multiplicitate.
Multiplicitatea
47
Multiplicitatea indic numrul de obiecte susceptibile de a participa la o asociere dat. n general, multiplicitatea m..p indic numrul minimal m i maximal p de obiecte care pot participa la asocierea respectiv. Notaia 0..* reprezint plaja de la 0 la infinit. n exemplul de mai sus, multiplicitile ataate rolurilor a i b conduc la urmtoarea interpretare: unei instane a clasei B i se pot ataa mai multe obiecte aparinnd clasei A (sau chiar nici un obiect), n timp ce o instan a clasei A trebuie s fie legat obligatoriu la un singur obiect aparinnd clasei B.
Exemplu
Remarci: n exemplul de mai sus, clasele conceptuale Client i Comanda sunt figurate numai cu dou compartimente (fr operaii) a se vedea studiul de caz e-commerce. Atributele email i ntrepr pot uneori s lipseasc, ceea ce este notat cu semnul [0..1]. Asocierea poart numele consult_comenzile_sale i se refer, evident, la client. Fiind bidirecional, aceast asociere poate fi notat, de exemplu, i cu aparine_unui i atunci se refer la comand. Un client poate consulta mai multe comenzi care i aparin. De asmenea, pot exista clieni care nu au nc ataat vreo comand. O comand, dac exist, poate aparine unui singur client.
Navigabilitatea
48
Navigabilitatea indic o asociere unidirecional. n reprezentarea de mai sus, sgeata ndreptat de la clasa A spre clasa B arat c un obiect al clasei B poate dispune de toate instanele clasei A asociate acestuia, dar nu i invers.
Exemplu
Atributele
Remarci: S relum exemplul precedent, transformnd asocierea bidirecional ntr-o asociere unidirecional. Navigabilitatea de la clasa Comanda la clasa Client, arat c un client poate dispune de toate comenzile sale, n schimb, o comand nu poate ti crui client i aparine. Din punctul de vedere al specificaiei de interfa, aceast reprezentare arat c responsabilitatea pentru gestiunea comenzilor de care dispune un client aparine exclusiv acestuia. Nu se specific cum se realizeaz acest asociere (prin pointeri sau referine). Acest lucru va fi indicat n modelul de implementare. Atributele sunt asemntoare asocierilor. La nivel conceptual, atributul nume al unui client arat c acesta are un nume. La nivelul specificaiei de interfa, se arat c un obiect client rspunde de acest atribut i poate s furnizeze numele su. La nivelul implementrii, un client are un cmp numit i variabil de instan sau dat membru a clasei Client care conine numele su.
Sintax UML
vizibilitate nume: tip = valoare_implicit n care: vizibilitate
+ public - vizibil de oriunde - private - vizibil din interiorul clasei # protected - vizibil din interiorul clasei respective i din interiorul tuturor claselor derivate din aceasta
nume ir de caractere tip

integer, long, float, string, alt tip de dat (nestandard) valoare, de tipul enunat, cu care va fi iniializat acest atribut
valoare_implicit
49
Operaiile
Operaiile enun procesele pe care o clas le poate realiza sub form de metode. n cadrul modelului conceptual nu se utilizeaz, de regul, operaii.
Sintax UML
vizibilitate nume (list_de_parametri): list_de_tipuri_de_ntoarcere n care: vizibilitate
Se utilizeaz, n schimb, operaii pentru a specifica interfaa unei clase. Din punctul de vedere al specificaiilor de interfa, operaiile corespund metodelor publice de un anumit tip (vizibilitate=public). n mod obinuit, nu se noteaz acele operaii care nu fac dect s manipuleze atributele clasei respective (crearea, actualizarea sau extragerea acestor atribute), ntruct acestea trebuie s existe, oricum. n modelul de implementare operaiile se detaliaz, aprnd i meniunea de private i protected, de la caz la caz.
nume ir de caractere list_de_parametri conine parametri separai prin virgule, a cror sintax este asemntoare atributelor, adic direcie nume: tip = valoare_implicit singura diferen fiind direcie care arat c parametrul este utilizat n: intrare (in); ieire (out); intrare-ieire (inout). list_de_tipuri_de_ntoarcere list de tipuri integer, long, float, string, alt tip de dat (nestandard),separate prin virgul
+ public - vizibil de oriunde - private - vizibil din interiorul clasei # protected - vizibil din interiorul clasei respective i din interiorul tuturor claselor derivate din aceasta
Generalizarea
50
Generalizarea este o relaie de forma subtip ntre clase. n plan conceptual, putem spune c A i B sunt un fel de C sau A i B sunt subtipuri ale supertipului C dac toate instanele claselor A i B sunt, prin definiie, i instane ale clasei C. Rezult de aici c toate enunurile referitoare la C (atibute, operaii, asocieri) sunt, de asemenea, valabile pentru A i B. n modelul de specificaii, generalizarea se traduce prin aceea c
Clasificarea
dac se substituie un subtip unui supertip n orice poriune de cod, programul continu s funcioneze normal. Din punct de vedere al implementrii i al limbajului de programare, generalizarea este asociat motenirii. Subclasa motenete toate cmpurile i metodele superclasei. Subclasa poate redefini metodele motenite i uneori poate afecta chiar sensul generalizrii. n acest caz, se poate renuna la acel subtip n modelul de specificaii. Generalizarea se reprezint ca o asociere terminat cu un triunghi alb cu vrful ndreptat spre clasa generalizant. Clasificarea este un mod de generalizare care definete relaia ce leag un obiect de un tip. Clasificarea unic: un obiect nu poate aparine dect unui singur tip, care poate moteni supertipuri. Clasificarea multipl: un obiect poate fi descris prin mai multe tipuri, care nu sunt n mod obligatoriu asociate printr-o relaie de motenire. Clasificarea static: nu permite schimbarea tipului, odat definit. Clasificarea dinamic: permite obiectelor s-i schimbe tipul n interiorul unei structuri de subtip. De exemplu, dac un cont bancar, la un moment dat, nu mai are acoperire, este necesar redefinirea unor operaii retragerea unei sume, nchiderea contului etc ceea ce face util trecerea lui n alt categorie (subtip).
interfaa subtipului trebuie s conin toate elementele de interfa ale supertipului (este conform interfeei supertipului). Altfel spus,
Exemple
51
Remarci: Diagrama de mai sus reprezint un exemplu de clasificare multipl [Fowler&Kendall], pag.108. Supertipul Persoan conine discriminatorul sex (Brbat, Femeie), discriminatorul rol (Kinoterapeut, Infirmier, Medic), discriminatorul pacient (Pacient). La rndul su, Medic, prin intermediul discriminatorului specializare, poate fi de specialitile Medic chirurg sau Medic de familie, care constituie, la rndul lor, subtipuri ale supertipului Medic. O persoan, brbat sau femeie, poate fi, n acelai timp, medic de subtipul medic chirurg, sau poate avea calitatea de pacient. Se nelege c nu toate combinaiile sunt corecte, de exemplu, nu poate fi, n acelai timp brbat i femeie sau medic i infirmier, subtipurile aparinnd aceluiai nivel de discriminare fiind disjuncte.
Remarc. Diagrama de mai sus reprezint un exemplu de clasificare dinamic [Fowler&Kendall], pag.110. O persoan, brbat sau femeie, poate avea, la un moment dat, funcia de vnztor, inginer sau manager. Funcia se poate modifica datorit evoluiei calitilor persoanei n cauz, conjuncturii etc. Dac subtipurile necesit comportamente speciale, devine mai interesant transformarea lor n clase legate la Persoan prin asocieri (roluri) a se vedea studiul de caz e-commerce.
Agregarea
52
Agregarea exprim relaia un obiect aparinnd clasei B este o parte a unui obiect aparinnd clasei A. Este evident c un obiect al clasi A este legat prin agregare de prile sale componente instane ale clasei B. Un obiect al clasei B poate aparine ns, n acelai timp, mai multor tipuri de agregri obiecte ale lui A. Agregarea este marcat cu un romb vid n spre clasa care conine obiectul agregant.
Exemple
Remarc. n exemplul de mai sus - [Fowler&Kendall], pag.111 se arat c un stil poate aparine, n acelai timp, i unui poligon i unui cerc. Att cercul ct i poligonul pot utiliza ns mai multe stiluri pentru a le caracteriza, printre care i stilul nostru scos n eviden prin multiplicitatea 1 ataat clasei din care face parte.
Remarc. Acest exemplu aparine studiului de caz e-commerce i arat c o tem cuprinde prin agregare un ansamblu de cri (cel puin una), ns o carte poate face parte din mai multe teme (eventual, din nici una).
Compunerea
Compunerea este o agregare mai puternic i mai restrictiv, n sensul c obiectul clasei B care este parte a unei instane a clasei A nu mai poate face parte dintr-o alt instan. El definete n mod unic obiectul clasei A din care este parte, avnd aceeai durat de via cu acesta. Compunerea este marcat cu un romb plin situat n spre clasa care conine obiectul compus.
Exemple
Remarc. Acest exemplu aparine studiului de caz e-commerce i arat c un obiect din clasa Co este compus dintr-un ansamblu de instane LinieCo (cel puin una). Dispariia obiectului din clasa Co duce la dispariia tuturor instanelor care l definesc.
53
Remarc. Exemplul de mai sus aparine de asemenea studiului de caz e-commerce i arat c un obiect al clasei CardBancar (dac exist) aparine strict unui singur client (instan a clasei Client).
Remarc. n acest exemplu extras din diagrama claselor conceptuale pentru Gestiunea materialelor propus ca tem de aplicaie la sfritul acestui capitol se arat c obiectul CatalogMateriale este unic pentru toate materialele componente, cu alte cuvinte se lucreaz cu un singur catalog, iar toate materialele pot fi identificate n mod unic n cadrul acestuia.
Remarc. n exemplul de mai sus - [Fowler&Kendall], pag.111 se arat c orice instan a clasei Punct poate exista fie ntr-un poligon, fie ntr-un cerc, dar niciodat n ambele simultan. Distrugerea poligonului antreneaz dispariia punctelor sale asociate (orice poligon este definit prin cel puin 3 puncte, dispuse ntr-o anumit ordine). La fel, dispariia cercului - definit prin punctul care marcheaz centrul - face s dispar acest punct.
54
Remarc. Un alt mod de a reprezenta relaia de compunere este de a plasa componentul n interiorul compusului relaiile se refer la exemplul precedent.
Pachete de clase
Obiectele reprezint cel mai sczut nivel de abstractizare. Ele activeaz ncapsularea prin includerea propriilor lor atribute. Modularizare nseamn limitarea accesului de la stare ctre metodele clasei. Dar UML permite i accesul public la atribute, ceea ce nseamn renunarea la modularitate. Pe de alt parte, colecia de obiecte existente n cadrul unui proiect precum i interaciunile dintre obiecte sunt, de regul, prea detaliate pentru a lucra direct cu acestea. Este nevoie de un mecanism pentru a combina clasele i a crea straturi intermediare de abstractizare. Cum rezolvm aceast dilem? Soluia o ofer pachetele.
Pachetul este un mecanism general de regrupare a elementelor UML, utilizat, n principal, n analiza i concepia obiectelor pentru a regrupa clase i asocieri.
La nivelul cel mai de jos, un pachet este o colecie de clase, ale cror obiecte colaboreaz n vederea producerii de servicii. O clas poate aparine unui singur pachet. Mai departe, dei nu constituie o restricie, fiecare clas trebuie s aparin unui pachet. Pachetele pot fi combinate pentru a forma pachete mai generale .a.m.d. Astfel se formeaz o ierarhie de abstractizri. Arhitectura sistemului este capturat de ctre pachetul de proiectare. Modelul obiect este o ierarhie de pachete de clase. Rdcina ierarhiei este nivelul cel mai nalt. Ramurile sunt clasele. Acestea pot fi reprezentate ntr-o diagram (vezi figura 3.8).
Figura 3.8 Limbajul UML: ierarhie de pachete
55
n UML pachetele sunt dependente dac exist clase membru dependente n fiecare pachet. Notaia pentru pachete i dependenele dintre pachete se vede n figura 3.9.
Figura 3.9 Limbajul UML: asocierea pachetelor
Ca i clasele, dependenele pot fi bidirecionale sau unidirecionale. O dependen este este unidirecional atunci cnd metode de clas dintr-un pachet pot apela metode de clas dintr-un alt pachet, dar nu i invers. n figura 3.6, obiecte din clase aflate n pachetul A pot fi apelate prin metode ale unor obiecte aflate n pachetele B i C. Obiecte din B pot fi apelate n A, dar nu i obiectele din C. Dac obiectele claselor pachetului A pot fi apelate din C, spunem c A depinde de C. n acest caz, C poate fi dezvoltat, n principiu, separat i independent deoarece obiectele sale nu pot fi apelate de nicieri.
56
Specificarea detaliat a cerinelor. Fia-tip a cazurilor de utilizare
n acest capitol: Descrierea detaliat a cazurilor de utilizare Scenarii: scenariul nominal, extensii, precondiii, postcondiii, cerine suplimentare Fia-tip a cazurilor de utilizare
Descrierea detaliat a cazurilor de utilizare

n capitolele precedente am identificat actorii i cazurile de utilizare. Acum vom nva s descriem cazurile de utilizare n detaliu, pentru a obine o exprimare precis a necesitilor nainte de a ataca analiza i construirea n detaliu a obiectelor. n final vom nva s completm o fi-tip pentru fiecare caz de utilizare.
Scenarii
Putem considera cazurile de utilizare drept o colecie de scenarii de succes sau eec, ce descriu modul n care un anumit actor utilizeaz sistemul pentru a atinge un obiectiv. Cazul de utilizare trebuie s aib un nceput i un sfrit, clar definite. Trebuie precizate toate variantele posibile, ncercnd totodat s ordonm secvenial descrierile pentru a ameliora lizibilitatea. Exist dou tipuri de scenarii: scenariul nominal i extensiile sale. Scenariul nominal: permite satisfacerea obiectivelor actorilor prin calea cea mai direct de succes.
57
Extensiile: conin toate celelalte scenarii de succes (sfrit normal) sau eec (excepii). Fiecare scenariu este compus din etape, care pot fi: un mesaj al unui actor ctre sistem; validare sau o schimbare a strii sistemului; un mesaj al sistemului ctre un actor. Etapele sunt numerotate secvenial, pentru a putea indica apoi extensiile posibile. Extensiile sunt foarte importante. Ele indic toate celelalte scenarii sau ramificaii posibile, att de succes ct i de eec. Convenia de numerotare ne ajut s le legm de scenariul nominal. Astfel, unei etape X, o prim extensie va fi notat cu Xa i va identifica: mai nti condiia care provoac extensia, i apoi rspunsul sistemului. Principiul const n descrierea condiiei care s poat fi detectat de sistem. Apoi, rspunsul sistemului poate cuprinde una sau mai multe etape, numerotate secvenial. O a doua extensie referitoare la X se va nota cu Xb .a.m.d.
Fia-tip a cazurilor de utilizare

Descrierea n detaliu a unui caz de utilizare se bazeaz pe o fi-tip care descrie textual cazul i care propunem s cuprind urmtoarele rubrici 14: actorul principal, eventual actorii secundari, obiectivul, precondiii, postcondiii, scenariul nominal, extensiile, i eventual cerine suplimentare. Un rezumat al principalelor caracteristici ale fiei-tip a cazurilor de utilizare este artat n figura 4.1.
58
Figura 4.1 Fia-tip a cazurilor de utilizare rezumat Fia-tip a Explicaii cazurilor de utilizare Rol Fia-tip are rolul de a detalia fiecare caz de utilizare, fcnd s
apar clar comportamentul sistemului i al actorilor care iau parte la fiecare aciune proprie cazului de utilizare respectiv.
14
Fia-tip nu este normalizat de UML
Elemente componente Cnd se utilizeaz Exemplu 15
Actorul principal, actorii secundari, obiectivul, precondiii, postcondiii, scenariul nominal, extensii, declanatorul, cerine suplimentare. Se utilizeaz ca punct de plecare pentru diagrama de secven, diagrama de colaborare, diagrama de activiti, diagrama de stare i toate celelalte diagrame de tip comportamental. Fia tip: Cumprarea unui produs Obiectiv: Satisfacerea nevoii clientului Scenariul nominal: 1. Clientul parcurge catalogul i selecteaz articolele. 2. Clientul acceseaz pagina de validare a comenzii. 3. Clientul furnizeaz informaiile privind livrarea (adresa de livrare, condiiile de livrare). 4. Sistemul afieaz preul, inclusiv costul transportului. 5. Clientul furnizeaz informaii referitoare la cartea sa de credit. 6. Sistemul autorizeaz vnzarea. 7. Sistemul trimite un e-mail de confirmare clientului. Extensii: 3a: Clientul este un client de baz: 1. Sistemul afieaz informaiile curente referitoare la tarife, livrare i facturare. 2. Clientul le poate accepta sau modifica; ntoarcere la etapa 6 a scenariului nominal. 6a: Sistemul nu autorizeaz cumprarea pe credit. Clientul poate introduce din nou informaiile pe cartea sa de credit, sau s o anuleze.
Elementele fiei-tip a cazurilor de utilizare sunt detaliate n figura 4.2.
Figura 4.2 Elementele fiei-tip a cazurilor de utilizare Elementele fiei-tip a cazurilor de utilizare
Actorul principal
Explicaii
Fiecare caz de utilizare are un actor principal, care interacioneaz cu sistemul n vederea realizrii unui serviciu. Actorul principal este acela cruia sistemul
59
15
Vezi [Fowler2] Martin Fowler - UML 2.0 CampusPress, 2004, pag.121.
Actorii secundari Obiectivul Scenariul nominal
Extensiile
Precondiiile Postcondiiile
60
ncearc s-i satifac obiectivul i este, de regul, iniiatorul cazului de utilizare. Pot exista, uneori, i ali actori cu care sistemul comunic pe durata realizrii cazului de utilizare. Acetia poart numele de actori secundari. Obiectivul enun beneficiul pentru actorul principal realizat n cazul de utilizare respectiv. Scenariul nominal descrie, n amnunt, desfurarea evenimentelor n cadrul unui caz de utilizare, sub forma unor aciuni succesive ale actorului principal (eventual i ale actorilor secundari) urmate de rspunsuri ale sistemului. Scenariul nominal presupune c aciunile se desfoar normal, se primesc n modul cel mai direct - rspunsurile ateptate din partea sistemului i totul se termin prin atingerea obiectivului cazului de utilizare respectiv. Fiecare aciune poart numele de etap. O etap poate fi: enunul unei proceduri (din partea actorului sau sistemului), enunul unui mesaj (din partea actorului sau sistemului), schimbarea unei stri a sistemului. Convenie de notaie: n cadrul scenariului nominal etapele se desfoar secvenial i sunt notate 1, 2, ... , n. O extensie nominalizeaz o condiie care antreneaz interaciuni diferite de cele descrise n scenariul nominal. O extensie este totdeauna o consecin a uneia din etapele scenariului nominal. Convenie de notaie: cifr, care indic etapa de plecare din cadrul scenariului nominal, urmat de liter a, b, ... care indic varianta (de rspuns, de stare, de mesaj etc). n cadrul unei extensii, aciunile se renumeroteaz ncepnd de la 1, 2,... O precondiie descrie ceea ce sistemul trebuie s verifice nainte de a autoriza nceperea cazului de utilizare. O postcondiie descrie ceea ce sistemul trebuie s se asigure la sfritul cazului de utilizare. Dup fiecare scenariu nominal exist o postcondiie de
Declanatorul Cerine suplimentare
succes. Extensiile nu pot avea dect, eventual, postcondiii minimale. Uneori se specific i evenimentul care provoac demarajul cazului de utilizare respectiv, care poart numele de declanator. Exist situaii n care este necesar adugarea unor cerine suplimentare, referitoare la frecvena de repetare a cazului de utilizare, condiiile n care are loc acest scenariu etc (vezi cazul de utilizare ntreinerea catalogului din cadrul studiului de caz e-commerce).
Observaie: VP-UML ofer o facilitate de descriere a cazurilor de utilizare dup
un model apropiat de acela al fiei-tip definit mai sus (vezi capitolul 12, figura 12.11).
61
Diagramele de secven sistem (DSS)
n acest capitol: Diagramele de secven sistem
Diagramele de secven sistem

Diagramele de secven sistem (DSS) fac parte din categoria diagramelor care exprim comportamentul sistemului proiectat. Se reprezint, de regul, scenariul pentru fiecare caz de utilizare n parte. Vom utiliza termenul de diagrame de secven sistem pentru a sublinia faptul c sistemul informatic figureaz, n aceste diagrame, ca o cutie neagr. Comportamentul sistemului este descris ca fiind vzut din exterior, fr a lua n consideraie cum a fost realizat. Cutia neagr va fi detaliat cu ocazia diagramelor de specificaii.
Principalele caracteristici ale diagramei de secven sistem

Un rezumat al principalelor caracteristici ale diagramelor de secven sistem este artat n figura 5.1.
62
Figura 5.1 Principalele caracteristici ale diagramelor de secven sistem Diagrama UML de Caracteristici secven sistem Reprezentare
Rol
Elemente componente Cnd se utilizeaz
Diagrama de secven sistem descrie comportamentul instanelor actorilor i al sistemului (global) prin intermediul mesajelor emise i primite de acetia ntr-un caz de utilizare dat. Diagrama de secven sistem reprezint o implementare posibil a scenariului cazului de utilizare respectiv. Instanele actorilor i ale sistemului global considerate ca obiecte de sine stttoare, liniile lor de via, mesajele emise i primite de fiecare obiect, reprezentate secvenial. Diagrama de secven se utilizeaz ori de cte ori se dorete vizualizarea comportamentului mai multor obiecte (ale actorilor, ale subsistemelor) n interiorul unui caz de utilizare. Diagrama de secven sistem consider sistemul n totalitatea sa ca pe o singur clas i trateaz instanele sale ca atare.
63
Exemplu
S ne referim la exemplul scenariului de cumprare a unui produs, reprodus dup Fowler n figura 4.1 din cadrul capitolului 4, i s ncercm s-i reprezentm diagrama de secven sistem.
Remarci: n aceast diagram s-a reprezentat numai scenariul nominal. Clientul caut n catalog articolul dup cuvinte cheie. Completarea formularului de comand include informaiile privind livrarea (adresa de livrare, condiiile de livrare). Autorizarea livrrii este reprezentat aici printr-o operaie n interiorul sistemului. O alt variant ar fi expedierea unui mesaj Serviciului Clieni care s preia aceast sarcin (vezi studiul de caz e-commerce Efectuarea comenzii).
64
______________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________
Elementele diagramei de secven sistem

Elementele diagramei de secven sistem sunt detaliate n figura 5.2.
Figura 5.2 Elementele diagramei de secven sistem Elementele diagramei de secven sistem
Instanele actorilor
Explicaii
Actorii care intervin ntr-o diagram de secven sunt considerai drept clase iar instanele lor se reprezint precum instanele claselor, adic:
<nume_instan> : <nume_actor>
Remarc. Numele instanei nu este obligatoriu.
Instana sistemului
Sistemul se consider o singur clas (global) iar instana sa se reprezint n modul clasic, adic:
<nume_instan> : <nume_sistem>
Remarc. Numele instanei nu este obligatoriu.
Liniile de via
Mesajele
Liniile de via ale fiecrui obiect se reprezint sub forma unei linii ntrerupte verticale care pornete de la simbolul obiectului respectiv i dureaz atta timp ct exist obiectul, adic se termin mesajele care pleac sau sosesc n acesta. Mesajele se reprezint prin linii orizontale terminate cu sgei, care pleac de la linia de via a obiectului emitent i ajung la linia de via a obiectului receptor. Mesajele se reprezint secvenial, de sus n jos, urmrind etapele scenariului nominal. Convenie de notaie: De obicei, mesajele care pleac de la actori se noteaz ca proceduri (de regul fr parametri sau cu parametrii considerai eseniali pentru nelegerea procedurii).
65
Exemplu: cutareArticole (cuv.cheie)
Mesajele care pleac de la sistem se reprezint cu linie ntrerupt i se noteaz ca un simplu text. Mesajele care pleac de la sistem se pot nchide n ele nsele dac reprezint sarcini pe care le poate rezolva numai sistemul. Detalierea ulterioar a diagramelor de secven (cu ocazia specificaiilor de interfa) vor pune n eviden subsistemele crora le revine obligaia s rezove aceste sarcini. (Exemplele de mai sus se refer la diagrama de secven sistem reprezentat n figura 5.1).
Exemplu: articole gsite
Exemplu: autorizare a vnzrii
66
Clasele de analiz participante i tipologia lor. Diagrama claselor participante (DCP)
n acest capitol: Clasele de analiz participante i tipologia lor: dialog, control, entitate Diagrama claselor de analiz participante (DCP)
Clasele de analiz participante i tipologia lor

Exist trei tipuri de clase de obiecte participante la analiz pentru fiecare caz de utilizare 16, definite prin urmtoarele stereotipuri: clase de tip grani; clase de tip control; clase de tip entitate.
Clasele de tip grani (boundary)

Clasele de tip grani (sau dialog) reprezint conexiunea ntre obiectele interne ale sistemului i lumea exterioar. Cele mai uzuale fac parte din interfaa utilizatorului, de exemplu ferestre sau cutii de dialog. Cititoarele de coduri de bare fac parte din aceeai categorie.
67
16 A se vedea [Jacobson] I.Jacobson - The Unified Software Development Process, Addison Wesley, 1999, p.44 i [Roques1] Pascal Roques UML 2 par la pratique. Etudes de cas et exercices corrigs, Editions Eyrolles, Paris, 2004, pag.220
n cazul nostru, clasele de grani mbrac forma de dialog i permit interaciunea ntre site-ul Web i utilizatorii si (ecrane interactive, formulare de culegere a datelor, prezentarea rezultatelor cutrii etc.).
Clasele de tip control

Clasele de tip control conin cinematica aplicaiei. Ele fac tranziia ntre clasele de tip grani i clasele de tip entitate care conin date persistente (n baze de date). Clasele de tip control ne asigur c nu vom uita funcionalitatea sau comportamentul dezvluit prin cazurile de utilizare.
Clasele de tip entitate

Clasele de tip entitate reprezint obiecte specifice modelului domeniului care trebuie memorate de sistem, fie ntr-o baz de date, fie, cel puin, dincolo de terminarea cazului de utilizare respectiv. Modelul conceptual al domeniului este sursa multora din clasele de tip entitate dar, pe parcursul analizei, vor putea interveni i alte clase de obiecte de tip entitate.
Diagrama claselor participante (DCP)

Diagrama claselor participante este o diagram de tip UML care descrie, prin intermediul cazurilor de utilizare, principalele clase de analiz i relaiile dintre ele. Diagrama claselor participante este deosebit de important deoarece face jonciunea ntre cazurile de utilizare, modelul domeniului, machetele de interfa cu utilizatorul (IOM) i diagramele de concepie a programelor reprezentate prin diagramele de interaciune i diagramele de clase. Diagramele claselor participante se obin prin completarea diagramelor claselor conceptuale cu atribute, operaii precum i cu asocieri.
68
Reguli
n realizarea diagramelor claselor participante se vor respecta urmtoarele reguli: 1. Clasele de tip entitate vor avea numai atribute, acestea reprezentnd, de regul, informaiile persistente ale aplicaiilor; 2. Clasele de tip control vor avea numai operaii, acestea artnd logica aplicaiei, regulile specifice, comportamentul sistemului; 3. Clasele de tip grani vor cuprinde att atribute ct i operaii. Atributele vor reprezenta cmpuri de introducere de date sau cmpuri de rezultate. Rezultatele vor fi reprezentate utiliznd notaia de atribut derivat. Operaiile vor reprezenta aciuni ale utilizatorului asupra interfeei ommain (IOM). Asocierile ntre clasele de analiz vor respecta urmtoarele reguli: 1. Clasele de tip grani nu pot fi legate dect de clasele de tip control sau de alte clase de tip grani. n general, asocierile sunt unidirecionale n sensul de la dialog ctre control, n afar de cazul cnd acesta din urm creaz un nou dialog (cu date de ieire); 2. Clasele de tip entitate nu pot fi legate dect de clase de tip control sau de alte clase de tip entitate. Asocierile sunt totdeauna unidirecionale, n sensul control ctre entitate; 3. Clasele de tip control au acces la toate tipurile de clase, inclusiv la alte controale. Dac adugm n cadrul diagramelor i actorii, acetia trebuie s se supun urmtoarei reguli: 1. Un actor nu poate fi legat dect la o clas de tip grani (dialog).
Principalele caracteristici ale diagramei claselor participante la analiz (DCP)

Un rezumat al principalelor caracteristici ale diagramelor claselor participante la analiz (DCP) este artat n figura 6.1.
69
Figura 6.1 Principalele caracteristici ale diagramei claselor participante Diagrama UML a Caracteristici claselor participante la analiz (DCP) Reprezentare
Rol
Diagrama claselor participante la analiz (DCP) descrie, prin intermediul cazurilor de utilizare, principalele clase de analiz i relaiile dintre ele. DCP face jonciunea ntre cazurile de utilizare, modelul domeniului, machetele de interfa cu utilizatorul (IOM) i diagramele de concepie a programelor reprezentate prin diagramele de interaciune i diagramele de clase. Actori participani la cazurile de utilizare, clase de grani (dialog), clase de control, clase entitate, asocieri (marea majoritate unidirecionale).
DCP se utilizeaz n faza de analiz, atunci cnd se dorete vizualizarea claselor participante n interiorul unui caz de utilizare. Diagrama claselor participante consider sistemul descompus n partea care asigur interfaa cu utilizatorul, partea care asigur interfaa cu bazele de date i partea de sistem care realizeaz cinematica aplicaiei (control). S ne referim la exemplul scenariului de cumprare a unui produs, reprodus dup Fowler n figura 4.1 din cadrul capitolului 4, i s-i reprezentm diagrama claselor participante la analiz (DCP). Remarci: Clientul caut n catalog articolul dup cuvinte cheie. Completarea formularului de comand include informaiile privind livrarea (adresa de livrare, condiiile de livrare). Dup calcularea comenzii se ntorc informaiile referitoare la pre, costul transportului, condiiile de livrare. Pentru livrare este necesar inroducerea informaiilor referitoare la client i cartela sa de credit. Autorizarea vnzrii se face de ctre controlul comenzii, dup ce acesta a luat cunotin de la controlul clienilor de valoarea creditului clientului.
Exemplu
70
71
Elementele diagramei claselor participante

Elementele diagramei claselor participante la analiz sunt detaliate n figura 6.2.
Figura 6.2 Elementele diagramei claselor participante la analiz (DCP) Elementele diagramei Explicaii claselor participante
Clasele de grani (dialog)
Clasele de tip grani reprezint interfaa ntre sistem i lumea exterioar acestuia. Ele cuprind att atribute ct i operaii. Atributele reprezint cmpuri de introducere de date sau cmpuri de rezultate (formulare, pagini de Web etc). Operaiile reprezint aciuni ale utilizatorului asupra interfeei om-main. Clasele de tip grani nu pot fi legate dect de clasele de tip control sau de alte clase de tip grani. Clasele de control
72
Clasele de tip control conin cinematica aplicaiei. Ele fac tranziia ntre clasele de tip grani i clasele de tip entitate care conin date persistente. Clasele de tip control conin numai operaii, acestea artnd logica aplicaiei, regulile specifice, comportamentul sistemului. Clasele de tip control au acces la toate tipurile de clase, inclusiv la alte controale.
Clasele de tip entitate
Clasele de tip entitate reprezint obiecte specifice modelului domeniului care trebuie memorate de sistem, fie ntr-o baz de date, fie, cel puin, dincolo de terminarea cazului de utilizare respectiv. Clasele de tip entitate nu pot fi legate dect de clase de tip control sau de alte clase de tip entitate. Asocierile sunt totdeauna unidirecionale, n sensul control ctre entitate.
73
Modelarea dinamic. Diagramele de interaciune: diagrama de secven i diagrama de colaborare
n acest capitol: Comunicarea ntre obiecte Diagramele de secven Diagramele de colaborare
Comunicarea ntre obiecte

n capitolul precedent am menionat cteva dintre specializrile claselor (dialog, control, entitate), construind asocieri ntre acestea n cadrul cazurilor de utilizare. Cu aceast ocazie am identificat cteva operaiuni poteniale pentru clasele de tip dialog i control. Acestea au rezultat dintr-o prim abordare. n acest capitol ne vom concentra pe problemele cruciale de comportament ale claselor, care definesc modelarea dinamic. Definirea dinamicii unui sistem pornete de la studierea scenariului. n cadrul acestui scenariu evolueaz obiecte care schimb ntre ele mesaje. Aadar, modelarea dinamic are n primul rnd n vedere definirea mesajelor care circul ntre obiecte. Reprezentarea grafic a mesajelor se face cu ajutorul diagramelor de interaciune. Diagramele de interaciune sunt de dou feluri: diagrame de secven i diagrame de colaborare (sau de comunicare, conform UML 2.0). Ne vom ocupa de acestea n paragrafele imediat urmtoare. Observaii: 1. Atunci cnd descriem un mesaj care circul ntre dou obiecte s spunem ntre un obiect al clasei A, emitent, i un obiect al clasei B,
74
receptor, acestui mesaj i corespunde de fapt o operaie public n clasa obiectului receptor (vezi figura 7.1). Rezult c prin diagramele de interaciune, am mbogit, de fapt, clasele cu noi operaii ale modelului dinamic.
Figura 7.1. mbogirea claselor cu operaii din diagramele de interaciune
2. Atribuirea responsabilitilor unor clase adecvate este una din cele mai dificile probleme ale concepiei orientate obiect. O responsabilitate nseamn, de fapt, un serviciu sau o funciune a sistemului atribuit unei clase. Diagramele de interaciune sunt deosebit de utile pentru a reprezenta grafic deciziile proiectantului cu privire la alocarea responsabilitilor. Fiecare diagram va reprezenta astfel un ansamblu de obiecte aparinnd unor clase diferite, care colaboreaz n cadrul unui scenariu de execuie al sistemului. Obiectele comunic, trimindu-i unul altuia mesaje care invoc operaii sau metode ale obiectelor receptoare. Astfel, se pot urmri vizual interaciunile dinamice ntre obiecte i prelucrrile realizate de fiecare obiect. Cartelele CRC La sfritul anilor 1980, unul din cele mai mari centre de tehnologie orientat obiect l constituiau laboratoarele de cercetare Textronix n Portland. Doi renumii programatori n Smalltalk, Ward Cunningham i John Beck, au inventat o tehnic simpl de a nva modelarea orientat obiect: cartelele CRC (Classe-Respnsability-Collaboration). Ei reprezentau clasele pe fie i n loc de a indica atribute i metode puneau n eviden responsabiliti.
75
Ideea era de a se debarasa de descrierea datelor i a procesului i a se concentra n descoperirea obiectivului clasei n chestiune. Al doilea C nsemna punerea n eviden a claselor colaboratoare. Acest lucru ddea o idee despre legturile ntre clase, chiar dac era vorba numai de o descriere de nivel nalt. Unul din principalele avantaje ale cartelelor CRC era acela c stimula discuiile ntre dezvoltatorii de software asupra unor aspecte eseniale ale viitoarelor soluii, chiar de la nceputul proiectrii. 3. Fa de diagramele de secven sistem, de care ne-am ocupat n capitolul 5, o astfel de diagram de secven detaliat se obine nlocuind sistemul vzut ca o cutie neagr cu un ansamblu de obiecte care colaboreaz ntre ele. Aceste obiecte nu vor fi altele dect cele evideniate cu ocazia proiectrii diagramelor claselor participante la analiz (DCP) vezi capitolul 6 aparinnd tipurilor dialog, control sau entitate. Vor fi respectate urmtoarele reguli de colaborare ntre aceste tipuri de obiecte: actorii nu pot trimite mesaje dect dialogurilor; dialogurile pot interaciona numai cu controalele sau, n mod excepional, cu alte dialoguri; controalele pot interaciona cu dialoguri, entiti sau cu alte controale; entitile nu pot interaciona dect ntre ele. Schimbarea nivelului de abstractizare al diagramelor de secven, n raport cu diagramele de secven sistem, se poate reprezenta ca n figura 7.2.
Figura 7.2 Schimbarea nivelului de abstractizare al diagramelor de secven
76
Diagramele de interaciune nglobeaz dou tipuri de diagrame UML, care (ambele) servesc la exprimarea nteraciunilor ntre mesaje: diagramele de secven i diagramele de colaborare. Acestea vor fi detaliate n continuare.
Un rezumat al principalelor caracteristici ale diagramelor de secven este prezentat n figura 7.3.
Figura 7.3 Principalele caracteristici ale diagramelor de secven a mesajelor obiectelor participante la analiz Diagrama UML de Caracteristici secven a mesajelor obiectelor participante la analiz Reprezentare
Rol
Elemente componente Cnd se utilizeaz Exemplu
O diagram de interaciune descrie un ansamblu de obiecte i relaiile dintre ele, ca i mesajele care pot circula ntre obiecte. Diagrama de secven este o diagram de interaciune care pune accentul pe aranjarea mesajelor n ordinea lor cronologic. O diagram de secven este un tablou n care obiectele sunt dispuse n lungul unei axe a absciselor, iar mesajele, n ordine cresctoare a apariiei lor, de-a lungul axei ordonatelor. Linia de via, perioada de activitate. Diagramele de secven se utilizeaz atunci cnd se dorete vizualizarea comportamentului mai multor obiecte n cadrul scenariului unui caz de utilizare. Ne referim la exemplul diagramei de secven care reprezint comanda unui produs, propus de Fowler 17, i adaptat de noi pentru a pune n eviden obiectele claselor participante la analiz (DCP).
77
17
[Fowler2] Martin Fowler - UML 2.0 CampusPress, 2004, pag.68.
78
Remarci: Cumprtorul trimite mesajul prin care cere s i se comunice preul comenzii sale. Mesajul este introdus n sistem prin intermediul unei instane a clasei de tip dialog AfiCom. Mesajul calcPre () este transmis unei instane a clasei de tip control ContrLinCom care gestioneaz o linie de comand. n scopul calculului, aceasta cere i obine de la o instan a clasei de tip entitate Produse (de exemplu, din baza de date) preul unitar pentru produsul pr al liniei de comand. Pe baza acestui pre i cunoscnd atributul qt (cantitate) aflat n linia de comand, instana :ContrLinCom calculeaz preul brut al produsului pe care l returneaz instanei de afiare :AfiCom. Acum instana :AfiCom cere instanei :ContrLinCom detaliile de livrare (adresa livrrii, condiii speciale etc) pentru a putea calcula preul livrrii. n acest scop, instana :ContrLinCom consult o instan a clasei de tip entitate Clieni (de exemplu, din baza de date). Detaliile privind livrarea produsului ajung n final la instana :AfiCom care calculeaz costul livrrii. Calculul preului brut al produsului din linia de comand, respectiv calculul costului livrrii produsului, se reprezint prin bucle recursive care pleac i se nchid n aceeai linie de via a instanei
:ContrLinCom, respectiv :AfiCom.

n final, preul total al comenzii, care cuprinde suma preurilor produselor din toate liniile de comand, este comunicat cumprtorului.
Elementele componente ale diagramelor de secven sunt detaliate n figura 7.4.
Figura 7.4 Elementele componente ale diagramelor de secven Elementele diagramei de Explicaii secven a mesajelor obiectelor participante la analiz
Linia de via
Linia de via a unui obiect este linia vertical ntrerupt care reprezint existena unui obiect pe o anumit perioad de timp. n reprezentarea de mai sus, obiectul este o instan oarecare a clasei Clas. Majoritatea obiectelor care apar n diagram exist pe toat durata interaciunilor, fiind aliniate n partea de sus a diagramei, linia lor de via ajungnd n partea inferioar a acesteia. Exist ns i obiecte create pe durata interaciunilor, a cror linie de via ncepe la recepionarea mesajului create.
79
Obiectele pot fi distruse n timpul interaciunilor. n acest caz, linia lor de via se termin la recepionarea mesajului destroy.
Bara de activare
Fiecare linie de via posed o bar de activare, care arat durata de activitate a participantului la interaciune. Aceasta corespunde, de fapt, timpului n care operaia respectivei instane este activ. Barele de activare sunt facultative, dar n acelai timp, ele sunt foarte utile pentru clarificarea comportamentului obiectelor.
80
Mesajul de rspuns
Mesajul de rspuns (returul) i acesta neobligatoriu - este, de asemenea, util pentru corelarea participanilor la diagram. Returul nu se indic dect acolo unde se consider necesar pentru nelegerea diagramei. Imbricarea
Imbricarea unei perioade de activitate se reprezint printr-o bucl care se nchide n bara de activare. Imbricarea se datorete fie unei recursiviti, fie unui apel al unei operaii interne, fie unei chemri de ctre un alt obiect. Imbricarea se reprezint printr-o bar de activare care se nchide n ea nsi, figurat pe jumtate n interiorul barei de activare principale, puin n dreapta acesteia.
Diagramele de colaborare
Un rezumat al principalelor caracteristici ale diagramelor de colaborare este prezentat n figura 7.5.
81
Figura 7.5 Principalele caracteristici ale diagramelor de colaborare Diagrama UML de Caracteristici colaborare a obiectelor participante la analiz Reprezentare
Rol
O diagram de colaborare pune n eviden organizarea obiectelor care particip la o interaciune. n acest scop, aa cum se arat n reprezentarea de mai sus, se schieaz, mai nti, obiectele care particip la interaciune, apoi legturile lor prin arce, eventual etichetate. n cele din urm, se marcheaz semnalele pe care obiectele le trimit i, respectiv, le recepioneaz. Drumul, numrul de secven. Diagramele de colaborare se utilizeaz atunci cnd se dorete modelarea fluxului de control prin organizare. Acest gen de modelare scoate n eviden relaiile structurale ntre instane care permit schimbul de mesaje. Diagramele de colaborare permit vizualizarea iteraiilor de ramificare condiional complexe ca i a fluxurilor de control concurente. Ne referim la exemplul diagramei de secven din subcapitolul precedent, care reprezint comanda unui produs, pe care o transformm ntr-o diagram de colaborare ntre instanele claselor participante la analiz.
Exemplu
82
Elementele componente ale diagramelor de colaborare sunt detaliate n figura 7.6.
Figura 7.6 Elementele componente ale diagramelor de colaborare Elementele diagramei de Explicaii colaborare a obiectelor participante la analiz
Drumul
Drumul servete pentru a indica legarea unui obiect de altul. n exemplul de mai sus, obiectul obX aparinnd clasei Clasa1 este legat de obiectul obY al clasei Clasa2 iar acesta din urm de
83
Mesajul
Numrul de secven
Iteraia
Condiia
obiectul obZ al clasei Clasa3. Opional, drumul poate fi etichetat (vezi stereotipurile <<b<<,<<c>>). Pe acest drum circul mesaje. Mesajul este notat cu o sgeat paralel cu drumul i o declaraie a mesajului, de obicei sub form de operaie (vezi opY(), opZ()). Pentru a indica ordinea cronologic a unui mesaj care circul pe un drum, fiecare mesaj este precedat de un numr care indic secvena (vezi 1. opY(), 2. opZ()). Pentru a indica mesajele imbricate (care decurg unul drept consecin a mesajului precedent), se poate utiliza notaia zecimal 1., 1.1., 1.1.1. etc. O iteraie reprezint o secven repetat de mesaje. Pentru a modela o iteraie, se prefixeaz numrul de secven al mesajului cu expresia unei iteraii, de exemplu: *[1 := 1..n], sau pur i * fr a intra n detalii. Aceasta simplu presupune c mesajul respectiv (i toate mesajele coninute de acesta) se vor repeta, conform expresiei date. O condiie reprezint un mesaj a crui execuie este subordonat evalurii unei expresii booleene. Pentru a exprima o condiie, trebuie s precedm numrul de secven al unui mesaj cu o clauz condiional, de exemplu: [x > 0]. Ramificrile care urmeaz vor avea acelai numr de secven, dar se vor diferenia n mod unic printr-o condiie exclusiv, de exemplu: [x = 0], [x < 0].
Remarc. Pentru iteraii i ramificaii condiionale UML nu prescrie forma de exprimare ntre paranteze. Putem utiliza tot att de bine sintaxa unui limbaj de programare specific.
84
Modelarea dinamic. Diagramele de stare i diagramele de activiti
n acest capitol: Stri i activiti Diagramele de stare Diagramele de activiti
Stri i activiti
n capitolul precedent am dezvoltat dou tipuri de diagrame UML diagramele de secven i diagramele de colaborare - care se dovedesc extrem de utile n modelarea dinamic a obiectelor. n acest capitol vom continua s ne ocupm de modelarea dinamic, aducnd n discuie alte dou tipuri de diagrame de stare i de activiti - care ntregesc mijloacele de studiere a comportamentului obiectelor. O stare reprezint o situaie din timpul vieii unui obiect n care acesta: satisface o condiie; execut o anumit activitate; ateapt un anumit eveniment. Un obiect trece printr-o succesiune de stri pe durata existenei sale. O stare are o durat finit, variabil n conformitate cu viaa obiectului i n funcie de evenimentele cu care se confrunt. n UML, un eveniment arat c se petrece ceva semnificativ, localizat n timp i spaiu. Diagramele mainilor de stare constituie o tehnic curent care a permis descrierea comportamentului unui sistem nc din anii 1960. Aceast tehnic a fost adoptat i n ultimile orientri obiect pentru a pune n eviden, de regul, comportamentul unui singur obiect al unei clase, pe durata ciclului su de via.
85
n contextul mainilor de stare, un eveniment reprezint un stimul care poate declana o tranziie ntre stri. UML propune patru tipuri de evenimente 18: 1. Recepionarea unui semnal trimis de un alt obiect sau un actor. Trimiterea semnalului este, de regul, asincron, adic apare atunci cnd este cazul. Exemplu: excepiile n limbajele C++ i Java (try {...}catch(Exception e){...}). 2. Apelul unei operaii a obiectului receptor (call event) pe care acesta trebuie s o execute. Evenimentul apelului este sincron, adic execuia urmeaz imediat apelului. 3. Trecerea timpului (time event) un cuvnt cheie (after) urmat de o expresie care reprezint o durat socotit de la intrarea n starea curent. 4. O schimbare n satisfacerea unei condiii (change event). Se utilizeaz cuvntul cheie when, urmat de o expresie boolean. Evenimentul de schimbare se produce atunci cnd condiia devine adevrat.
Diagramele de stare
Maini de stare i diagrame de stare

O main de stare specific secvena strilor pe care un obiect o poate parcurge pe timpul duratei sale de via, ca rspuns la evenimentele care i parvin, ca i reaciile corespunztoare acestor stri. O diagram de stare este, n esen, o proiecie a elementelor care apar ntr-o main de stare. Aceasta nseamn c poate conine ramuri, puncte de sincronizare, fluxuri concurente, stri de aciune, stri de activitate, obiecte, stri iniiale, stri finale, stri cu istoric etc. Nu toate obiectele claselor necesit o reprezentare prin diagrame de stare. Se reprezint printr-o main a strilor, de regul, comportamentul complex al obiectelor claselor. Pentru a gsi aceste obiecte cu comportament deosebit, este util s ne ntrebm:
86
18 [Roques&Valle] - UML en action: De lanalyse des besoins la conception en Java, Edition Eyrolles, Paris, 2000 et 2003, Chapitre 8: Dveloppement du modle dynamique, Les quatre types dvnements en UML, p.176.
obiectul acelei clase poate reaciona n mod diferit la apariia aceluiai eveniment? n acest caz, fiecare tip de reacie caracterizeaz o stare diferit a obiectului; clasa din care face parte obiectul trebuie s-i organizeze anumite operaii ntr-o ordine precis? n acest caz, strile secveniale permit precizarea cronologic forat a activrii evenimentelor.
Caracteristicile diagramelor de stare

Un rezumat al principalelor caracteristici ale diagramelor de stare este prezentat n figura 8.1.
Figura 8.1 Principalele caracteristici ale diagramelor de stare Diagrama UML Caracteristici de stare a obiectelor participante la analiz Reprezentare
O diagram de stare se reprezint printr-un graf orientat, n care n noduri avem strile iar arcele sunt tranziiile. Strile se reprezint prin dreptunghiuri cu colurile rotunjite iar tranziiile de la o stare la alta prin sgei care unesc dreptunghiurile respective. Fiecare tranziie este marcat prin trei elemente: evenimentul declanator al tranziiei (exemplu: ev1 marcheaz declanarea tranziiei Stare1 -Stare2); n paranteze patrate, condiia declanrii (exemplu: cond1 marcheaz condiia declanrii tranziiei Stare1 Stare2); activitatea asociat tranziiei (exemplu: act12 este activitatea asociat tranziiei Stare1 Stare2). Cele trei elemente nu sunt obligatorii. Lipsa activitii arat c nu
87
se ntmpl nimic pe durata tranziiei. Lipsa condiiei arat c tranziia are loc necondiionat, imediat ce apare declanatorul. Lipsa declanatorului este mai rar dar nu imposibil i arat c tranziia se produce imediat. Atunci cnd dintr-o stare pleac mai multe tranziii, fiecare tranziie trebuie s aib propriul su eveniment declanator sau, dac exis un acelai element declanator, condiiile declanrii trebuie s fie diferite. n cadrul strilor se pot produce i alte evenimente, care nu sunt evenimente declanatoare.
Rol Elemente componente Cnd se utilizeaz
Exemplu
O diagram de stare are rolul de a arta succesiunea de stri prin care poate trece un obiect pe durata existenei sale. Stare, tranziie, eveniment declanator al tranziiei, condiie pentru efectuarea tranziiei, activitate ataat tranziiei. Diagramele de stare se utilizeaz atunci cnd se dorete vizualizarea comportamentului unui obiect pe parcursul unuia sau mai multor cazuri de utilizare. Ele nu sunt bine adaptate reprezentrii comportamentului mai multor obiecte care colaboreaz ntre ele. Ne referim la exemplul diagramei de secven prezentat n capitolul 7, care reprezint comanda unui produs. S reprezentm diagrama de stare a cumprtorului:
Stare1: starea de pornire a calculului iterativ pentru :AfiCom. Aciune: mesajul de calcPre() trimis controlului. Stare2: :AfiCom ateapt preul produsului. Eveniment declanator: primete preul produsului prin afi.produs. Aciune: cere detalii livrare de la control. Stare3: :AfiCom ateapt detalii livrare. Eveniment declanator: primete detalii livrare prin detalii livrare. Aciune: calculeaz costul livrrii declannd operaia intern calculCostLivr() dup care calculeaz preul comenzii. Stare4: Ateapt terminarea calculului comenzii. Aciune: lanseaz controlului :ContrLinCom ntrebarea dac mai
sunt linii de comand de parcurs. Stare5: Ateapt rspuns. Eveniment declanator: Rspuns nr linii rmase nrlin. Tranziie retur: Condiie nrlin>0. Tranziie terminat: Condiie nrlin=0. Aciune terminat: Transmite cumprtorului preul comenzii.
88
Remarci:
Starea de pornire aparine cumprtorului. Evenimentul declanator : cumprtorul cere calcularea
preului comenzii sale. n acest moment, ntreaga operaie este pasat obiectului :AfiCom (pagin Web) care efectueaz o serie de operaii iterative pentru toate liniile de comand. Acestea alctuiesc o super-stare Stare_calcul_comand, care nglobeaz strile prin care trece de fapt :AfiCom i, n final, remite preul comenzii cumprtorului. Starea final: cumprtorul primete preul cerut i obiectul :AfiCom dispare.
89
Elementele componente ale diagramelor de stare

Elementele componente ale diagramelor de stare sunt detaliate n figura 8.2.
Figura 8.2 Elementele componente ale diagramelor de stare Elementul diagramei Explicaii de stare a obiectelor participante la analiz
Stare
O stare este o situaie n viaa unui obiect pe parcursul creia obiectul satisface unor condiii, execut o activitate sau ateapt un eveniment.
Eveniment
Un eveniment este specificarea unei ntmplri importante care are o amplasare n timp i spaiu. n contextul unei maini de stare, un eveniment este un stimul care poate declana o tranziie ctre alt stare.
Tranziie
Activitate Aciune
90
O tranziie este o relaie ntre dou stri: Stare1 i Stare2, care indic faptul c un obiect aflat n Stare1 execut unele aciuni, apoi intr n Stare2, dac un anume eveniment se produce i o serie de condiii bine precizate sunt ndeplinite. O activitate este o execuie a mai multor aciuni n curs n interiorul unei maini de stare. O aciune este un calcul ce nu poate fi ntrerupt (atomic, elementar) care d natere unei schimbri n cadrul unei stri a modelului, sau unei valori furnizate la ntoarcere.
Combinarea diagramelor de stare cu diagramele de secven

Diagramele de stare aduc un plus de precizie i exhaustivitate permind validarea i completarea diagramelor de interaciune. Ele pot incita, n egal msur, la completarea diagramelor existente. Ne referim la exemplul diagramei de secven prezentat n capitolul 7, care reprezint comanda unui produs, propus de Fowler 19, i adaptat de noi pentru a pune n eviden obiectele claselor participante la analiz (DCP). S marcm pe aceast diagram strile consecutive prin care trec obiectele (a se vedea figura 8.3).
Exemplu
Figura 8.3 Combinarea diagramelor de stare a obiectelor cu diagrama de secven pentru vnzarea unui produs
91
19
[Fowler2] Martin Fowler - UML 2.0 CampusPress, 2004, pag.68.
Remarci:
92
StareA1 este starea n care obiectul :AfiCom, care a primit mesajul de calculare a preului calculeazPre de la cumprtor i l-a transmis controlului :ContrLinCom, ateapt de la acesta din urm afiarea produsului cu detaliile de pre. ntre timp, obiectul :ContrLinCom trece prin dou stri consecutive: StareB11, care are ca aciune cererea getPre(pr) de livrare a preului produsului pr din linia de comand curent, din partea obiectului de tip entitate :Produse. La recepionarea cererii, obiectul :Produse tranziteaz spre StareC1 declannd totodat aciunea de cutare a preului n baza de date. La terminarea acestei aciuni, :Produse ntoarce mesajul pre unit care cuprinde preul unitar al produsului. Recepionarea mesajului pre unit de ctre :ContrLinCom declaneaz trecerea n starea urmtoare: StareB12, care are ca aciune calcularea preului brut al produsului prin nmulirea preului unitar cu cantitatea qt din linia de comand. n acest scop, se apeleaz operaia intern calculPreProd(qt). La terminarea calculului, se expediaz imediat mesajul afi.produs ctre obiectul :AfisCom. La primirea mesajului afi.produs i expedierea cererii detLivr() ctre :ContrLinCom, :AfisCom intr n StareA2 de ateptare a detaliilor de livrare din partea controlului. Recepionarea mesajului detLivr() scoate :ContrLinCom din starea de ateptare precedent i i provoac tranziia ntr-o nou stare numit StareB2. Acestei tranziii i se asociaz aciunea trimiterii mesajului getDetaliiLivrare() spre obiectul de tip entitate :Clieni. La recepionarea cererii, obiectul :Clieni tranziteaz spre StareD1 declannd totodat aciunea de cutare a detaliilor de livrare, n baza de date. La terminarea acestei aciuni, :Clieni ntoarce mesajul detalii livrare care cuprinde detaliile de livrare ale produsului. StareB2 ateapt primirea mesajului detalii livrare din partea obiectului :Clieni pentru a trece n starea de ateptare final StareB3. La primirea detaliilor de livrare, acestea sunt transmise obiectului :AfiCom (aciune asociat tranziiei spre StareB3). Primirea detaliilor de livrare declaneaz calculul costului livrrii i intrarea :AfiCom n StareA3. Costul livrrii este efectuat chiar de :AfiCom, prin declanarea operaiei interne calculCostLivr(). Totodat, se va aduna costul livrrii la preul produsului i acesta din urm la preul total al comenzii. n sfrit, se va lansa ctre :ContrLinCom ntrebarea cte linii de comand au mai rmas de prelucrat. Ieirea din StareA3 este declanat de mesajul de rspuns care conine nrlin numrul liniilor rmase de parcurs. Din StareA3, tranziia se poate face: spre StareA1, dac mai exist linii de comand neparcurse nc (nrlin>0); spre StareFinal, dac nu mai exist linii de comand neparcurse (nrlin=0). Tranziiei spre starea final i se asociaz aciunea comunicrii preului total al comenzii. Starea final coincide cu distrugerea tuturor instanelor claselor participante.
Recomandri pentru elaborarea diagramelor de stare

Pentru a elabora diagrame de stare v recomandm urmtoarele etape: Reprezentai, mai nti, secvena strilor care descriu comportamentul nominal al unui obiect, de la naterea pn la dispariia sa, mpreun cu tanziiile asociate. Adugai progresiv tranziiile i strile corespunztoare comportamentelor alternative. Integrai apoi tranziiile i strile corespunztoare erorilor. Completai diagrama cu aciunile care declaneaz fiecare tranziie i, eventual, cu activitile corespunztoare din interiorul strilor.
Activiti i fluxuri de control

O diagram de activiti este, n esen, o organigram care ilustreaz fluxul de control de la o activitate la alta (workflow). Ea este un instrument ideal pentru descrierea logicii procedurale. Diagrama de activiti se utilizeaz pentru a modela aspectele dinamice ale unui sistem. n timp ce diagramele de interaciune pun accentul pe colaborarea ntre obiecte, diagramele de activiti evideniaz n special interaciunea ntre activiti. O activitate este o execuie neatomic, compus, de regul, din mai multe aciuni consecutive. Activitile sfresc prin a produce ceva, care provoac schimbarea strii unui sistem sau ntoarcerea unei valori.
Caracteristicile diagramelor de activiti

Un rezumat al principalelor caracteristici ale diagramei de activiti este prezentat n figura 8.4.
93
Figura 8.4 Principalele caracteristici ale diagramei de activiti Diagrama UML Caracteristici de activiti Reprezentare
94
Rol
Remarci: n reprezentarea de mai sus, Activ.2 i Activ.3 sunt activiti concurente (care se desfoar n paralel). ntre ramificaie i jonciune trebuie s fie o sincronizare perfect, n sensul c toate activitile care pleac din ramificaie trebuie s se termine n jonciune pentru a se putea trece mai departe. Punctul decizional trebuie s fie marcat de o condiie pentru a se putea alege una din cile de continuare a procesului. n cazul de fa condiia este boolean. Dac exist mai multe rspunsuri posibile, ele trebuie s fie exclusive i fiecare rspuns trebuie s marcheze o cale de continuare. Fuziunea marcheaz sfritul unui comportament condiional iniializat printr-o decizie. Fiecrei decizii trebuie s-i corespund un punct de fuziune corespunztor. Oricum ar continua, trebuie s existe un punct final al procesului. Intrarea i ieirea sunt reprezentate obligatoriu n diagram.
Diagrama de activiti permite responsabilului procesului s
aleag ordinea execuiei. Diagrama de activiti enun regulile de desfurare a procesului, punnd n eviden relaiile ntre activiti. Elemente Activitate, arc, nod, drum, ramificaie, jonciune, ramur, componente punct de decizie, condiie, fuziune. Cnd se utilizeaz Punctul forte al diagramelor de activiti este acela c ele permit reprezentarea paralelismelor n cadrul proceselor, fiind un excelent instrument de ilustrare a fluxurilor de activiti (workflows). Exemple 1. S reprezentm, de exemplu, diagrama de activiti n cazul livrrii unei comenzi. Diagrama ncepe cu activitatea de primire a comenzii, de ctre Serviciul Clieni, i se sfrete cu nchiderea comenzii, efectuat de acelai serviciu. Pregtirea comenzii i livrarea se desfoar n paralel cu trimiterea facturii i primirea plii. Ambele ramuri trebuie s se termine printr-o jonciune nainte de nchiderea comenzii. Livrarea poate fi de dou feluri: livrare normal (n urma unei comenzi normale a clientului) sau livrare urgent, dac clientul pretinde acest lucru. Punctul de fuziune arat c oricare ar fi livrarea, aceasta trebuie s se termine nainte de nchiderea comenzii.
95
Observaie. Diagrama de mai sus arat ce se petrece dar
nu d nici un fel de indicaie asupra responsabililor acestor aciuni. Putem remedia acest defect dac vom efectua o partiionare a ariei de reprezentare, ca n exemplul urmtor. 2. S relum problema de mai sus, dndu-i, de aceast dat, o rezolvare mai cuprinztoare, n sensul c vom partiiona spaiul de reprezentare astfel nct, printr-o amplasare corespunztoare a aciunilor, se va putea indica i responsabilul acestora: Serviciul Expediii pentru pregtirea i livrarea comenzii, Serviciul Financiar pentru primirea plii i Serviciul Clieni pentru primirea comenzii, trimiterea facturii i nchiderea comenzii.
Observaii:
1. S-a renunat la detalierea activitii Livrarea comenzii n cele dou alternative Livrare normal i Livrare urgent. n definitiv, putem considera Livrarea comenzii drept o subdiagram n care figureaz schema decizional reprezentat n prima variant.
96
2. Aceast diagram a fost realizat i cu ajutorul pachetului de

programe Visual Paradigm for Unified Modeling Language, n cadrul capitolului 12.
Elementele componente ale diagramei de activiti

Elementele componente ale diagramei de activiti sunt detaliate n figura 8.5.
Figura 8.5 Elementele componente ale diagramelor de activiti Elementul Explicaii diagramei de activiti
Activitate
Ansamblu de aciuni atomice executate n vederea deplasrii ntr-o alt stare a sistemului sau obinerii unei valori.
Arc
Nod Drum Ramificaie
Segment (de linie continu) orientat, care leag dou activiti succesive, sau o activitate de un nod, sau un nod de o activitate. Intrarea i ieirea din diagram pot delimita, de asemenea, un arc. Ramificaie, jonciune, punct decizional, fuziune. Succesiune de arce.
Punct de declanare a mai multor evenimente paralele.
97
Jonciune
Punct de terminare a dou ramuri de activiti paralele.
Ramur Punct decizional
Drum cuprins ntre o ramificaie i jonciunea cu care se sincronizeaz.
Punct din care pleac mai multe drumuri de continuare a procesului. Alegerea unuia sau altuia dintre drumuri se face n funcie de ndeplinirea unei condiii. Fuziune
Loc n care drumurile care pornesc dintr-un punct decizional se unesc.
98
Proiectarea specificaiilor de interfa software. Diagramele de clas detaliate
n acest capitol: Elementele specificaiilor de interfa software Diagramele de clase detaliate
Elementele specificaiilor de interfa software

n capitolele precedente am realizat o diagram de clase conceptuale, n care neam concentrat atenia asupra relaiilor ntre aceste clase, evideniind numai cteva atribute eseniale. Apoi ne-am ocupat de aspectele comportamentale, pornind de la scenariile care detaliaz cazurile de utilizare. Diagramele de secven sistem au dezvluit un anumit comportament al actorilor fa de sistemul considerat n ntregul su. Apoi, acest sistem a fost spart n mai multe obiecte corespunztoare claselor de analiz: de tip grani sau dialog, de tip control i de tip entitate. Au fost alctuite diagrame de secven, respectiv diagrame de colaborare, n care au intervenit aceste clase. n sfrit, unele aspecte particulare ale comportamentului obiectelor au fost lmurite cu ajutorul diagramelor UML de stare i de activiti. Acum este momentul s trecem de la clasele de analiz la clasele care exist n software, fr a specifica ns despre ce software va fi vorba n faza de implementare. n definitiv, vor fi aceleai clase rezultate din analiz, pe care le vom detalia i le vom completa la maximum cu atribute, relaii i operaii, alctuind aa zisa specificaie de interfa cu programele care vor realiza aplicaia.
99
Diagramele de clase detaliate
Proiectarea claselor detaliate

Clase rezultate din analiz apar att n diagrama claselor participante la analiz (DCP), ct i n diagramele de interaciune de secven i de colaborare - pe care le-am conceput pentru fiecare caz de utilizare n parte. Clasele detaliate se obin dezvoltnd i completnd clasele participante la analiz, cu: indicatori de vizibilitate (public, protected sau private) pentru atribute; specificarea complet a atributelor: vizibilitate, tip i valoare iniial (nici una dintre aceste specificaii nu este obligatorie) conform prototipului: asocieri, indicatori de multiplicitate, generalizri /particularizri, agregri /compuneri (a se vedea capitolul 3); specificarea tuturor operaiilor cu toi parametrii acestora, conform prototipului:
[vizibilitate] nume_atribut [:tip] [= valoare_iniial];
[vizibilitate] nume_operaie (direcie nume_parametru [= valoare_implicit]...): [list_de_tipuri_de_ntoarcere]
[:tip]
Observaie. Semnificaia acestor notaii a fost explicat n cadrul capitolului 3.
Clase concrete i clase abstracte

Clasele concrete genereaz obiecte, adic instane de clase. O clas abstract este o clas care nu are obiecte. Fiecare clas abstract reprezint o idee. Numele clasei abstracte reflect faptul c este mai curnd un concept sau arhetip dect ceva specific (de exemplu, Vehicul clas abstract fa de Autoturism, Automobil_de_teren, Camion clase concrete). Relaia ntre clasa abstract i clasele concrete care o implementeaz este de generalizare /specializare. n clasa abstract este declarat numele operaiei, care este implementat prin metode (structuri sau cod de program) n clasele concrete care o particularizeaz.
100
S lum urmtorul exemplu de program scris ntr-un cod apropiat de cel al unui limbaj real pseudocod pentru a explica proprietile claselor abstracte. Programul trebuie s realizeze urmtoarele funciuni: s fie capabil s traseze linii drepte, cercuri i dreptunghiuri; s permit unei figuri create s fie mutat i umplut cu o culoare. Linia va fi definit prin dou puncte, de coordonate (x1, y1) i (x2, y2), cercul de punctul care fixeaz centrul (cx, cy) i de lungimea razei (r), iar dreptunghiul - tot de dou puncte (x1, y1) i (x2, y2), care fixeaz diagonala principal a dreptunghiului (stnga sus dreapta jos). S rezolvm problema creind mai nti clasa abstract denumit Figura, apoi cele trei clase concrete Linie, Dreptunghi i Cerc care implementeaz funciile enumerate mai sus (vezi figura 9.1).
Figura 9.1 Particularizarea clasei abstracte Figura de ctre clasele concrete Linie, Cerc i Dreptunghi care o implementeaz
Programul care definete clasa abstract Figura este ilustrat n figura 9.2.
101
Figura 9.2 Programul n pseudo-cod care definete clasa abstract Figura

class Figura {abstract} attribute new (in Nume: string) {abstract} move (in moveX: integer, in moveY: integer) {abstract} Programul care definete clasa concret Linie este ilustrat n figura 9.3.
Figura 9.3 Programul n pseudocod care definete clasa concret Linie

class Linie inherits from Figura attribute x1, y1, x2, y2: integer new (in Nume: string, in ex1: integer, in ey1: integer, in ex2: integer, in ey2: integer) x1 = ex1 y1 = ey1 x2 = ex2 y2 = ey2 move (in moveX: integer, in moveY: integer) x1 = x1 + moveX y1 = y1 + moveY x2 = x2 + moveX y2 = y2 + moveY Programul care definete clasa concret Cerc este ilustrat n figura 9.4.
Figura 9.4 Programul n pseudocod care definete clasa concret Cerc

class Cerc inherits from Figura attribute cx, cy, r : integer new (in Nume: string, in ecx: integer, in ecy: integer, in er: integer) cx = ecx cy = ecy r = er move (in moveX:integer, in moveY: integer) cx = cx + moveX cy = cy + moveY n final, prezentm un program care, pe baza definiiilor de mai sus, creeaz linia P care trece prin punctele (0, 0); (3, 1) i cercul Q avnd centrul n punctul
102
(0, 0) i raza 2, deplasndu-le cu x=3, y=4 de la locul n care au fost create (vezi figura 9.5).
Figura 9.5 Programul n pseudocod care creaz o linie i un cerc i le deplaseaz

linie = Linie.new (P, 0, 0, 3, 1) cerc = Cerc.new (Q, 0, 0, 2) linie1 = linie.move (3, 4) cerc1 = cerc.move (3, 4) Referitor la programele de mai sus putem face urmtoarele observaii: 1. Clasa abstract Figura nu conine atribute. 2. Operaia new n clasa abstract Figura conine numai parametrul Nume pentru numele figurii ce va fi generat. Aceast funcie va fi redefinit n clasele concrete Linie i Cerc, adugnd n plus, pentru Linie parametrii care definesc coordonatele celor dou puncte ale liniei ex1, ey1, ex2, ey2, iar pentru Cerc parametrii care definesc coordonatele centrului cercului ecx, ecy i raza er. 3. Operaia move pstreaz parametrii moveX, moveY, definii n clasa abstract Figura pentru deplasarea att a celor dou puncte care fixeaz linia ct i a centrului cercului pentru cerc. 4. Operaiile new i move sunt numai enunate n clasa abstract Figura. Procedurile care le sunt ataate acestor operaii sunt particularizate n clasele concrete Linie i Cerc n mod diferit pentru cele dou figuri. 5. Atributele enunate n interiorul celor dou clase concrete sunt de tip private. Ele nu pot fi modificate din exteriorul acestor clase. Metodele new i move, aparinnd celor dou clase, pot schimba aceste valori, aa cum se arat n programele din figurile 9.3 i 9.4. 6. Rezolvarea dat de noi mai sus nu se refer la trasarea curbelor respective ci numai la modificarea parametrilor care definesc aceste curbe. Observaie. n exemplul de mai sus nu a fost prezentat programul pentru clasa concret Dreptunghi. De asemenea, nu a fost atacat problema funciei fill de modificare a culorii de umplere a figurilor de mai sus.
103
Stratificarea pachetelor
n capitolul 3 am definit pachetul ca fiind un mecanism general de regrupare a elementelor UML. Referitor la clase, am menionat c este nevoie de un mecanism pentru a combina clasele i a crea straturi intermediare de abstractizare. Straturi obinuite sunt acelea care permit, de exemplu, lucrul cu interfaa utilizator sau cu bazele de date. Ceea ce rmne, poate fi grupat n stratul numit Proces. Dac ne referim la studiul nostru de caz e-commerce, n stratul Proces pot intra toate clasele de control ale cazurilor de utilizare (vezi figura 9.6). Stratul IOM (interfaa om-main) cuprinde toate clasele de tip dialog iar stratul Baza de date este compus din toate clasele de tip entitate care asigur interfaa cu baza de date a sistemului.
Figura 9.6 Stratificarea n pachete de clase pentru studiul de caz e-commerce
104
Caracteristicile diagramelor de clase detaliate

Un rezumat al principalelor caracteristici ale diagramelor de clase detaliate este prezentat n figura 9.7.
Figura 9.7 Principalele caracteristici ale diagramelor de clase detaliate Diagrama UML de Caracteristici clase detaliate Reprezentare
O diagram de clase detaliate se reprezint printr-o structur de clase, n care clasele i relaiile dintre ele apar completate cu atribute i operaii, ct se poate de detaliat, fr a se meniona ns aplicarea vreunui produs software limbaj sau pachet de programe. Aceasta constituie specificaia de interfa cu programele i pachetele de programe care vor realiza aplicaia. n descrierea detaliat a atributelor i operaiilor precum i a relaiilor ntre clase se folosesc conveniile i notaiile descrise n cadrul capitolului 3 pentru diagramele de clase. Rol O diagram de clase detaliate are rolul de a detalia specificaia de interfa pentru a pregti implementarea programelor i pachetelor de programe care vor realiza aplicaia. Elemente componente Clas, atribut, operaie, asociere, multiplicitate, navigabilitate, compunere, agregare, generalizare. Explicarea acestora a fost efectuat n cadrul capitolului
105
Cnd se utilizeaz Exemplu:
3. Diagramele de clase detaliate se utilizeaz n ultima faz a proiectrii, nainte de implementarea produselor software care vor realiza aplicaia.
106
n exemplul de diagram a claselor detaliate de mai sus, am reluat cazul cumprrii unui produs prelucrat de noi dup Fowler (vezi exemplul din capitolul 4, figura 4.1), a crui diagram a claselor participante la analiz (DCP) a fost ilustrat n capitolul 6, figura 6.1. Fa de diagrama DCP menionat, diagrama de mai sus prezint urmtoarele modificri: 1. S-a nlocuit parametrul cuvCheie cu carTeh caracteristicile tehnice ale produsului. 2. S-a schimbat numele operaiei cutareArticol n verifCautArt pentru a sublinia c se face o
3. 4.
5.
6.
7.
8.
verificare a formulrii corecte a cererii. Tipul boolean al acestei operaii sugereaz faptul c la o eventual eroare, aceasta se semnaleaz iar cumprtorul trebuie s reia cererea. Nu s-au reprezentat clasele de eroare i mesajele acestora. S-a adugat cutarea cautIdArt dup identificatorul articolului (cod, denumire etc) pentru a obine informaii detaliate despre articol. Clasa RezultCutrii n care se afieaz rezultatele cutrii a fost detaliat, n sensul c au fost artate operaiile: afiArticole, care afieaz lista articolelor gsite, claseazDupFurniz, care realizeaz un clasament al articolelor gsite dup furnizori, pagUrmPrec operaie care permite navigarea prin paginile de rezultat. Evident, mai pot fi realizate i alte tipuri de clasamente, dac acestea intereseaz cumprtorul. n clasa ControlCutArt au fost evideniate cele dou tipuri de prelucrri: cautArt dup caracteristici tehnice i cautIdArt dup identificatorul articolului. Pentru a se nelege modul n care se face cutarea, s-au detaliat legturile cu clasele de tip entitate Catalog, Articol i Furnizor, nsrcinate cu interfaa cu baza de date n care se gsesc aceste informaii. Formularul de comand FormComand din care se introduc informaiile pentru comad introInfoCom i se valideaz comanda validCom a fost separat de pagina de rezultate RezultComand n care se afieaz informaiile de detaliu ale comenzii: preul pre, costul transportului cosTran, data livrrii dataLivr i condiiile de livrare condLivr, cu ajutorul operaiei afiDetCom. A fost evideniat i clasa de tip entitate CarCredit legat de Client, pentru a arta modul n care clasa ControlClieni verific creditul prin intermediul operaiei confirCredit. Atributele au fost completate cu indicatorul de vizibilitate i tip, iar operaiile au fost detaliate cu indicatorii de vizibilitate i principalii parametri. Acolo unde s-a considerat necesar, parametrilor li s-au adugat tipul i indicatorii de direcie (in / out). Claselor de tip entitate li s-au adugat unele
107
atribute considerate eseniale pentru nelegerea operaiilor (idArt, denArt, carTeh pentru Articol, idFurn, numeFurn pentru Furnizor). 9. S-a renunat la simbolurile pentru tipurile de clase (dialog, control, entitate) care apreau n diagrama DCP.
108
10
UML i programarea. Arhitectura aplicaiilor Web. Soluii tehnice. Programarea bazat pe limbajul Java i servlets Java. Produse software pentru UML
n acest capitol: Arhitectura aplicaiilor Web Soluii tehnice pentru aplicaiile Web
Arhitectura aplicaiilor Web

n acest capitol ne propunem s prezentm mai nti cteva consideraii tehnice asupra prototipurilor arhitecturiale disponibile pentru aplicaiile Web. Un prototip arhitectural este expresia unei scheme fundamentale de organizare pentru sistemul de programe. Exist, la ora actual, un numr mare de produse i tehnologii disponibile legate de Internet. Oricare ar fi acestea ns, definirea arhitecturii de programare pleac de la necesitile aplicaiei. O aplicaie e-commerce implic existena a cel puin patru componente de baz: browserul clientului; serverul Web; serverul de aplicaii; serverul de date. n cazul unei aplicaii de tip universal destinate Internetului, configuraia clientului nu este controlabil. Clientul este un navigator Web standard, iar logica specific, ca i logica de prezentare, sunt integral executate pe server cu ocazia
109
prelucrrii cererilor navigatorului. Cererile navigatorului sunt formulate n limbajul HTML. Dac se folosete un browser mai nou, acesta permite i inseria unor programe n JavaScript care, eventual, pot face verificarea i validarea formularelor folosite de client nainte de trimiterea cererilor pe serverul Web. Aceasta duce la un ctig de timp considerabil. Dezavantajul este ns acela c JavaScript nu este neles n acelai mod de ctre toate variantele de browser i universalitatea programelor este ntructva afectat 20. Componentele majore ale acestui prototip arhitectural - Web universal precum i legturile dintre acestea sunt reprezentate n figura 10.1.
Figura 10.1 Arhitectura unei aplicaii Web
110
n diagrama din figura 10.1 componentele sunt reprezentate sub forma unor pachete UML. Modelul domeniului aplicaiei este reprezentat simbolic n pachetul numit Logica specific aplicaiei. Celelalte pachete au urmtoarele semnificaii:
20 De exemplu, JavaScript 1.5 nu este recunoscut oficial dect de Internet Explorer avnd versiunea minm 5.5 sau de Netscape Navigator avnd versiunea minim 6.0. A se vedea [Dumitrascu] Liviu Dumitrascu JavaScript, Editura Universitii din Ploieti, 2004
JavaScript. El acioneaz ca un dispozitiv universal de interfa utilizator, uneori avnd i funciune suplimentar de a accepta i retrimite ctre server cookies(a se vedea, mai jos, explicaia acestui termen). Prin intermediul conexiunii http (a se vedea mai jos explicaia acestui termen), utilizatorul aplicaiei cere pagini HTML de la server, care sunt afiate pe browser. Paginile retrimise conin o interfa n ntregime formatat, prezentat n fereastra client a browserului. Orice interaciune ntre utilizator i aplicaie trece prin browser. Serverul Web: este punctul de acces principal pentru toate browserele clienilor. n funcie de cerere (pagin HTML static sau pagin de server), serverul Web declaneaz sau anuleaz prelucrrile coninute n pagin. n toate cazurile, rezultatul este o pagin HTML care poate fi afiat de un browser HTML standard. Dac prelucrarea se refer la o pagin de script CGI, serverul deleag prelucrarea interpretorului de scripturi, dac este un modul ISAPI sau NSAPI deleag aceast prelucrare modulului executabil corspunztor (a se vedea n continuare explicaiile referitoare la CGI, ISAPI, NSAPI). Paginile de server: sunt pagini care sufer o form de prelucrare din partea serverului. De o manier mai general, aceste pagini sunt implementate pe server sub form de pagini de script (ASP-Active Server Pages sau JSP-Java Server Pages) care sunt tratate de ctre un filtru pe serverul de aplicaii sau de ctre un modul executabil (ISAPI Microsoft Internet Server API sau NSAPI Netscape Server API). Aceste pagini au acces potenial din partea serverului la toate resursele, inclusiv componentele logice specifice - baze de date sau sisteme tradiionale. Serverul de aplicaii: este principalul executant al logicii specifice din partea serverului i rspunde de execuia codului n paginile serverului. Se poate gsi pe aceeai main ca i serverul Web i poate fi executant n acelai spaiu de proces. Serverul de aplicaii este totui un element arhitectural logic distinct, deoarece nu este condiionat dect de execuia logicii specifice i deci poate pune n oper tehnologii altele dect cele ale serverului Web (de exemplu Enterprise Java Beans EJB sau Serviced Components - componente specifice reutilizabile gzduite de serverul de aplicaii Microsoft, care reprezint o evoluie a modelului COM). Serverul de date: permite gestionarea obiectelor specifice, de exemplu ntr-o baz de date relaional. Pentru a conecta baza de date la sistem, mijlocul cel mai simplu este de a permite accesul direct al scripturilor paginilor de server la componentele de persisten, acces care va trece totui prin utilizarea bibliotecilor standard de acces la date, ca de exemplu RDO (Remote Data Object), ADO (ActiveX Data Object), ODBC (Open Database Connectivity), JDBC (Java Database Connectivity) etc. Pagina HTML: este o pagin Web care cuprinde o interfa client i un coninut care nu este supus nici unei prelucrri din partea serverului. n general, aceste
Browserul: este un browser HTML standard, compatibil cu formularele i limbajul
111
pagini conin un text explicativ (help sau formular de introducere de date). Atunci cnd un server Web primete o cerere pentru o pagin HTML, el gsete fiierul asociat i l trimite retur clientului ignornd procedurile adresate serverului.
Definiii
serverul Web. De fiecare dat cnd clientul sau serverul i trimit unul altuia informaii, o nou conexiune se stabilete ntre ei. Exist i varianta unei conexiuni HTTP securizate, via SSL (Secure Socket Layer), care cripteaz informaiile transmise prin intermediul unei tehnologii speciale de criptare cheie privat /cheie public. Limbaj de descriere a coninutului, bazat pe cuvinte cheie (tag-uri). Acestea permit formatarea unui document pentru afiare sau imprimare. Tag-urile HTML sunt nominalizate de W3C: www.w3c.org. Paginile HTML sunt documente scrise n limbaj HTML. Ele sunt compuse din tag-uri, texte i legturi (link-uri) la alte resurse: alte pagini HTML, date multimedia (imagini, sunete etc), coninuturi active (applets, ActiveX, plug-ins). Program Java al crui cod este telencrcat de ctre client dintr-un server Web. El se execut apoi de ctre browser utiliznd un interpretor Java (main virtual sau JVM Java Virtual Machine care este integrat n majoritatea browserelor). Dei limbajul HTML, prin tehnicile script-urilor, poate fi utilizate de ctre neinformaticieni (de exemplu, de graficieni), utilizarea eficient a Java necesit cunotine prealabile n concepia i programarea obiect. Componente de program incluse n paginile HTML i telencrcate de ctre browser simultan cu aceste pagini. ActiveX se bazeaz pe COM (Component Object Model) infrastructura Microsoft n care dezvoltatorii pot construi componente n limbajul preferat i apoi le pot folosi pentru a elabora sisteme noi, mai complicate i mai puternice. Program telencrcat i instalat ntr-un browser. Atunci cnd browserul detecteaz un format de fiier (text, multimedia etc) pe care l recunoate, el face apel la plug-in-ul respectiv, pentru a-l trata.
Conexiunea http este protocolul cel mai rspndit ntre browserul clientului i
HTML
Applet
ActiveX
Plug-in
112
API Application Program Interface programe de interfa cu utilizatorul.
ISAPI Internet Server API extensie proprietar de server Web aparinnd Microsoft NSAPI Netscape Server API extensie proprietar de server Web aparinnd Netscape
Limbaj uor, dar relativ complex i puternic, care aduce funcii dinamice HTML n navigri pe browsere. n ciuda numelui su, el este foarte diferit de limbajul Java i nu este chiar orientat obiect (nu are moteniri). Un Web-service este un serviciu bazat pe Web, utiliznd XML (o form dezvoltat a HTML) pentru a codifica att ambalajul mesajului ct i coninutul corpului mesajului. Rezult o integrare total independent de sistemul de exploatare, de limbaj sau de oricare alt produs middleware utilizat de fiecare component care ia parte la serviciu. Mic ansamblu de informaii pe care un server poate s-l cear unui client s-l pstreze, pentru a-l restitui apoi. O aplicaie Web poate, de exemplu, s utilizeze un cookie tranzitoriu pentru ca serverul s poat lua urma unui anumit browser al clientului, de-a lungul parcursului su printre paginile site-ului Web. Cookie-urile permanente pot servi ca tichete de intrare virtuale, evitnd ca un client s fie obligat s reintroduc informaiile sale personale de acces, dar pot
JavaScript
Web- service
Cookie
constitui, n acelai timp, o cale uoar de infiltrare a unor programe de furt de informaii de la client!
ASP, JSP
Obiectivul acestor dou tehnologii este de a aduga cod script n paginile HTML. n timp ce JSP utilizeaz Java, ASP se bazeaz, n principal, pe VBScript. Aceste pagini sunt interpretate pe server, avnd astfel acces la resursele aplicaiei. Rezultatul acestei execuii este retrimis clientului.
Soluii tehnice pentru aplicaiile Web

113
Exist diferite soluii pentru dezvoltarea aplicaiilor Web. Iat cteva dintre acestea, n ordinea apariiei tehnologiilor pe care se bazeaz:
ctre serverul Web n timpul unei cereri. Acest program acceseaz toate resursele necesare, ca de exemplu baze de date, i construiete pagina n funcie de cerere. Aceast soluie prezint inconvenientul c mixajul de cod HTML cu cod de programare face dificil ntreinerea datelor, suprancarc memoria i ncetinete serviciul datorit lansrii procesului pentru fiecare cerere n parte. Tehnologia CGI nu este indicat pentru aplicaiile Web importante. Soluia bazat pe extensiile proprietar de servere Web: ISAPI (Microsoft), NSAPI (Netscape) i pe folosirea unor limbaje specializate pentru Web, precum Perl (Apache) sau PHP (o variant simplificat a Perl). Performanele sunt superioare soluiei bazate pe CGI. Soluia bazat pe ASP Active Server Pages (Microsoft) sau JSP Java Server Pages (Sun) adic pagini HTML active. Ele cuprind script-uri mici programe realizate n cod Visual Basic sau n cod Java care sunt executate n momentul n care sunt ntlnite n pagin. Soluia bazat pe Servlets Java Acestea sunt mici servere sau servicii scrise n Java, care utilizeaz un API specific. Ele corecteaz unele slbiciuni ale CGI: iniializate la creare, nu au dect o singur instan, care rmne disponibil pe parcursul ntregii aplicaii. Ele sunt rapide, performante i portabile, sub rezerva faptului c serverul Web n cauz trebuie s posede o main virtual Java ncorporat.
Soluia bazat pe CGI Common Gateway Interface. CGI este o tehnologie care permite apelarea unui program extern de
n cele ce urmeaz vom prezenta un studiu de caz pentru care vom alege o soluie bazat pe limbajul Java i Servlets Java.
Mai multe despre limbajul Java i servlet-uri

Java este un limbaj modern de programare orientat obiect, care s-a impus datorit atractivitii sale. Caracteristicile principale care au fcut din Java foarte atractiv sunt n parte prezente i n alte limbaje de programare i sunt urmtoarele: este un limbaj de programare orientat obiect; este multiplatform; permite programarea paralel; poate fi folosit pentru programarea aplicaiilor n reea i Internet; este un limbaj simplu i uor de folosit; elimin problemele legate de eliberare a memoriei. Un servlet este un program executat de ctre server, scris n limbajul Java, care prelucreaz cererile venite de la client i genereaz rspunsul ctre client. Java
114
astfel nct servlet-urile sunt portabile pe toate platformele i pe diferite servere web de aplicaii. Deoarece servlet-urile sunt scrise n Java, ele pot folosi ntreaga arhitectur Java API i de aceea ele sunt foarte utilizate pentru scrierea de aplicaii complexe. Spre exemplu, utiliznd Java Database Connectivity (JDBC) API permite programatorilor s scrie aplicaii care inteogeaz baze de date relaionale. Un servlet rspunde la aciunile utilizatorilor cum ar fi apsarea butonului de submit dintr-o form (form), colecteaz informaiile de la utilizator sau trimite napoi la utilizator rezultatele execuiei diverselor prelucrri asupra acestor date colectate. De asemenea, poate interoga bazele de date i transmite informaile cerute utilizatorului. Servlet-ul poate construi pagini HTML pentru afiarea informaiilor colectate sau a rezultatelor execuiei calculelor. Servlet-urile, ca orice instrument realizat prin limbajul Java, respect regula Write Once, Run Anywere, adic poate fi executat fr nici o modificare pe orice platform. Un servlet poate fi apelat de mai multe ori spre a servi cererile mai multor clieni. De asemenea, un servlet poate gestiona concurent cereri multiple i poate de asemenea s sincronizeze aceste cereri. Servlet-urile sunt executate de ctre servere web de aplicaii care permit execuia programelor scrise n Java. Serverele web de aplicaie sunt un tip special de servere Web ce permit ncrcarea, execuia i gestiunea servlet-urilor. Serverul folosete interpretorul Java Virtual Machine (JVM) pentru a putea executa servlet-urile. Servlet-ul construiete dinamic rspunsul folosind informaia extras din cererea clientului ( de regul un formular) plus datele pstrate n alte surse cum ar fi alte servlet-uri, obiecte partajate, fiiere de resurse, baze de date. Utilizarea unui servlet este prezentat n figura 10.8.
Servlet API definete interfaa standard pentru mesajele de cerere i de rspuns,
Figura 10.8 Utilizarea unui servlet
115
Astfel utilizatorul (1) cere serverului anumite informaii prin completarea unui formular (2) i acionarea butonului formularului (de tip Submit). Serverul (3) localizeaz servletul corespunztor prelucrrii cerute (4). Servletul se executa, obine rezultatele cerute i construiete documentul HTML de rspuns care se va afia n browser-ul utilizatorului. Prin urmare fluxul de date este urmtorul: clientul (de regul un browser) trimite cererea server-ului; serverul gsete servletul l instaniaz (ncarc) i creaz thread-ul (procesul) de prelucrare (execuie) a servletului. Un servlet este instaniat
la primul apel al lui i rmne instaniat pn la oprirea serverului.

serverul trimite cererea la servlet; servletul construiete rspunsul i l trimite serverului; serverul trimite rspunsul napoi clientului.
Apelarea unui servlet se poate face prin mai multe metode: apelarea explicit utiliznd adresa sa; inserarea servletului n HTML i apelarea sa atunci cnd utilizatorul dorete, spre exemplu, utilizarea unui formular; inserarea sa n alte servlet-uri. De regul un servlet este ncrcat atunci cnd acesta este invocat prima oar, dar poate fi ncrcat i la pormirea serverului de aplicaii. Pentru a crea un servlet, trebuie scris un program n limbajul Java care implementeaz interfaa javax.servlet.Servlet. Cel mai adesea se subclaseaz (extinde) clasa javax.servlet.GenericServlet din pachetul javax.servlet sau clasa javax.servlet.http.HttpServlet din pachetul javax.servlet.http.
Produse software pentru UML

Modul de abordare al programrii pentru aplicaiile construite cu UML prezentat mai sus nu este unic. De regul, aplicaiile importante se programeaz cu ajutorul pachetelor de programe specializate, de tip CASE, construite n acest scop de ctre marile firme de software, capabile s genereze n final, structura claselor n limbaj C++ sau Java. La aceste structuri, programatorul va aduga comportamentul dinamic al claselor, completnd aplicaia. n tabelul 10.2 este dat o list de produse software de firm care permit construirea diagramelor UML i generarea de cod n vederea realizrii proiectelor de aplicaii orientate obiect.
116
Tabelul 10.2 Produse software pentru UML

Nr. Firma crt proprietar 1 Arctaedius.com Denumirea produsului Principalele caracteristici ale produsului
2 3
analiza i proiectarea orientat obiect. Notaiile utilizate de ObjectPlant sunt un subansamblu al UML, care suport i OMT. Argouml.tigris.org ArgoUML ArgoUML este un instrument de modelare care v ajut n proiectarea cu UML Cay Horstmann Violet Violet este un instrument de desenat GPL foarte simplu, scris de Cay Horstmann, cel care a scris multe cri frumoase despre programarea n C++ i Java. DIA DIA Instrument de desenat gratuit /GPL bazat pe GTK. Suport UML i alte tipuri de diagrame. Se dorete a fi un produs gratuit de desenat Visiolike, mai curnd dect un instrument de modelare. Dispune de standarde compatibile Linux. EctoSet EctoSet Este un instrument UML bazat pe Windows, cu Modeller scripturi pentru forward engineering. Scripturile sunt prevzute pentru generarea codului Delphi, C++Builder, Java i VB. Valabil n versiunile standard i profesional, plus o exemplificare read-only gratuit. Excel Software WinA&D i Singurul instrument UML complet compatibil cu MacA&D platformele Win i Mac. Instrumentele de translatare pot genera modele de clase UML din C++, Java sau Object Pascal. FUJABA Forward Unto Genereaz cod n Java i reverse engineering, Java And Back este un produs de cercetare realizat sub LGPL, Again care suport diagramele de clase i diagramele de comportament UML. Gentleware ArgoUML Instrument de modelare a cercetrii bine dotat. Scopul principal este de a avea o interfa utilizator realmente util, asemntoare CASEurilor existente. Versiunea comercial se numete Poseidon i este comercializat de Gentleware. Se ofer i o versiune comun, gratuit, pe lng versiunile complexe, care sunt, n general, scumpe. HAT HOORA Analysis Prevede suport pentru UML utiliznd procesul Tool HOORA i sprijin importul de modele Rose, diagramele automate (modelul static, modelul dinamic, coninutul pachetelor), cerinele de
ObjectPlant
ObjectPlant este un program shareware pentru
117
10 11
Jude JVision
Jude JVision
12 13 14
Ken Dunnington Magic Draw MetaEdit
BlueJ Magic Draw MetaEdit+
15
Microsoft
Visio
16 17 18 19 20
ObjectDomain OmniGraffle Oracle ProxySource .com Rational
ObjectDomain
OmniGraffle i OmniGraffle Professional JDeveloper 10g JDeveloper 10g ruleaz pe Mac OS X. Produce un modelator built in UML care genereaz ProxyDesigner Rational Rose
management i trasabilitate, suportul ierarhic, dicionarul, generarea documentaiei Word, generarea codului C++, interfaa COM. Jude este un instrument UML gratuit disponibil n limbile Englez i Japonez. Versiunea plus se poate procura contra cost. Instrument comercial care ajut la reverse engineering i re-engineering a bibliotecilor cod surs Java n diagrame UML. Are un demo descrcabil. BlueJ este un mediu de nvare Java care suport notaiile UML. Este un instrument comercial, pur Java cu demo descrcabil. MetaEdit+ este un instrument forward engineering pentru proiectarea metodelor. Este att un CASE ct i un meta-CASE n care putei introduce propriile dumneavoastr subcomponente. Suport UML i cteva alte notaii. Ruleaz pe Win32, Unice i Linux. Este gratuit pentru utilizatorii necomerciali. Proiectat pentru a fi instrumentul comercial de desenat de top. Numai versiunea Enterprise (scump) suport integral modelarea UML. Alternativa ieftin poate desena diagrame UML utiliznd abloane Visio - cu care se pot realiza poze vanilla care arat ca UML dar nu furnizeaz referine ncruciate ntre diagrame. ObjectDomain este un instrument comercial. Suport integral UML. Este scris n Java pur i are un demo descrcabil. Dispun de colecii de faciliti UML.
118
21
Select Component Architect
Select Component Architect
clasele. Cost ntre 1000$ i 2000$. Instrument gratuit bazat pe PC pentru crearea i partajarea proiectelor software UML. Cel mai cunoscut instrument UML. Versiunea educaional se distribuie gratuit universitilor. Rational Rose RealTime (RRRT) este un mediu de dezvoltare care utilizeaz UML pentru crearea modelelor executabile. Este specializat n suportul UML pentru a ajuta n proiectarea bazat pe componente (Component Based Design CBD) i proiectarea sistemelor de afaceri (Business System Design BSD). Versiunile mai vechi se numesc Select
22 23
Sequence Sketcher SmartDraw
24
Technical University of Vienna
25 26
TogetherJ Visual Paradigm
Enterprise i Select OMT Professional. Este o aplicaie MacOS-X pentru trasarea numai a diagramelor de secven. SmartDraw este un concurent pentru Visio (mai curnd un instrument de desenat dect de modelat). Versiunea Pro cea mai scump suport UML. Ofert special pentru universiti. Ruleaz exclusiv pe platforme Win32. UMLet UMLet este un mic instrument de desenat, foarte simplu i uor de utilizat, construit de Technical University of Vienna. Este gratuit pentru nvmnt i utilizatorii necomerciali. Este pur Java, v.1 fiind mai mic de 60k., astfel nct poate fi utilizat de toat lumea, inclusiv de studeni care pot s-i construiasc propria copie personalizat. Acest instrument nu este scalabil i nu poate fi folosit pentru modelarea sistemelor mari. TogetherJ TogetherJ este un instrument comercial pur Java. Versiunea integral poate fi obinut gratis pentru uz academic. Visual Paradigm VP-UML este un CASE UML care suport for the Unified generarea codului Java. Sequence Sketcher SmartDraw Modeling Language (VPUML)
n cadrul capitolelor 11 i 12 care urmeaz, vom prezenta pe larg dou din aceste produse software i anume Rational Rose RealTime (RRRT) i Visual Paradigm for the Unified Modeling Language (VP-UML), care au stat la baza aplicaiilor practice propuse n capitolele 1-9 ale prezentei lucrri.
119
11
Rational Rose RealTime mediu UML pentru crearea modelelor executabile. Aplicaii
n acest capitol: Prezentarea general a mediului de dezvoltare RRRT care utilizeaz UML pentru crearea modelelor executabile Interfaa cu utilizatorul Adugarea unui caz de utilizare Crearea claselor i capsulelor
n acest capitol vom prezenta o modalitate direct de a genera cod executabil ca rezultat al utilizrii limbajului UML pentru crearea unor modele executabile. n acest scop, vom folosi pachetul de programe Rational Rose Real Time (RRRT) pe care l vom prezenta succint n cele ce urmeaz. Cu acest pachet, vom simula comportamentul unor capsule create special pentru un scenariu simplificat de gestionare a coului din cadrul studiului de caz e-commerce.
Prezentare general a mediului RRRT

utilizeaz UML pentru a crea modele executabile. Se tie c UML produce o mulime de construcii de modelare vizual. Nu toate aceste construcii sunt direct aplicabile pentru a crea un model activ. Multe dintre ele au drept scop proiectarea unor modele complexe, asigurnd departajarea sarcinilor pe echipe i comunicarea att ntre echipe ct i n interiorul echipelor de proiectare, facilitarea deciziilor, documentarea proiectului, dar care nu sunt obligatorii pentru a asigura funcionalitatea modelului.
Rational Rose RealTime (RRRT) este un mediu complet de dezvoltare care
120
Rational Rose RealTime produce construcii bazate pe elemente de modelare UML, fiind specializat n crearea modelelor executabile n timp real. Pentru a lucra cu Rational Rose RealTime trebuie s dispunei de RRRT Developer i un compilator Visual C++ 6.0 sau 7.0 instalat.
Interfaa cu utilizatorul
Rational Rose RealTime dispune de o interfa cu utilizatorul (vezi figura 11.1) format din urmtoarele componente:
Figura 11.1 Fereastra principal de interfa cu utilizatorul a RRRT
Bara standard este bara meniului principal File Edit View Browse Build Report Query Tools Add-Ins Window Help care rmne vizibil pentru toate vederile i
diagramele (vezi figura 11.2).
121
Figura 11.2 Bara de stare a RRRT
i este utilizat pentru adugare de elemente modelului, prin desenarea lor pe diagram. Elementele se schimb n funcie de diagrama activ la un moment dat. De exemplu, Diagrama cazurilor de utilizare (Use Case Diagram: Use Case View) are instrumente pentru adugare de actori, n timp ce Diagrama de clase (Class Diagram: Logical View) nu are acest instrument (vezi figura 11.3).
Bara de instrumente pentru diagrame apare n partea stng a diagramelor
Figura 11.3 Bara de instrumente pentru diagrama de clase Class Diagram: Logical View
122
Browser-ele situate n partea stng a ecranului, sunt ierarhice i pot fi expandate i contractate. La pornirea RRRT, apar browser-ele Containment View i Inheritance View n cadrul Model View. Se selecteaz tag-ul corespunztor din
partea inferioar a ferestrei (vezi figura 11.4).
Figura 11.4 Model View
Remarc. Browser-ele Structure/ State Diagram Browser/ Editor i Run Time System (RTS) Browser/ Editor nu pot fi mutate.
Vederile (Views) RRRT ofer 4 vederi principale situate n Model View

browser. Fiecare vedere este legat de o faz a ciclului de via, iar diagramele aferente sunt produsele (artifacts) ale acestor faze. Use Case View arat ce sistem (subsistem, clas sau interfa) trebuie construit, dar nu arat cum se realizeaz acesta (vezi figura 11.4). Logical View reprezint procesele arhitecturale pe care modelul le parcurge, de la analiz spre proiectare i realizare (vezi figura 11.4). Component View conine reprezentrile concrete ale sistemului. Componentele realizeaz clasele active (capsulele) i clasele de date i produce componentele de program pentru construirea i execuia modelului (vezi figura 11.4).
123
procesoarele i conine o diagram a nodurilor de sistem (vezi figura 11.4). Help-ul on-line furnizeaz informaii despre interfaa utilizator RRRT sau cum s se realizeze anumite sarcini specifice (vezi figura 11.5).
Deployment View arat cum este distribuit sistemul. El definete
Figura 11.5 Help-ul On-line
Procedur pentru crearea unui nou model

Pentru a crea un nou model, respectai urmtoarea procedur: 1. Executai click pe File / New.
Remarc. Atunci cnd se creeaz un nou model, se afieaz caseta de dialog Create New Model n care sunt listate 7 medii de lucru: Empty, RTC, RTC++, RTJava, StartupC, StartupCPP, StartupJ.
2. Pentru a deschide un model coninnd toate clasele cerute pentru dezvoltare utiliznd C++, executai click pe RTC++ (vezi figura 11.6).
124
Figura 11.6 Crearea unui nou model
Remarci: Putei schimba setrile pentru limbaj sau mediu, din menuul Tools, caseta de dialog Options, tab-ul Language/ Environment (figura 11.7).
125
Figura 11.7 Opiuni pentru schimbarea setrilor pentru limbaj sau mediu
Empty este util pentru crearea cazurilor de utilizare n proiectare, dar nu trebuie
utilizat pentru dezvoltarea aplicaiilor RRRT !
Pentru a crea un nou model i a specifica limbajul implicit, respectai procedura de mai jos:
1. Activai RRRT.
Remarc. Se afieaz cutia de dialog Create New Model; n caz de eec, executai click pe File / New continund cu punctul 2 ca mai sus.
126
2. Executai dublu click pe RTC++.
Remarc. RRRT iniializeaz un nou model, vid. Titlul (untitled) arat c modelul nu a fost nc salvat pe disc.
Configurarea setului de instrumente se realizeaz cu urmtoarea procedur:

1. n meniul Tools, executai click Options. 2. n Font/ Color facei gray, default diagram color. Diagram: default line type (oblique or rectilinear) and grid parameters. Line Attributes Dialog: Line style Oblique; Routing Normal; Smoothing: No smoothing; Jump links None. Compartments: Class Show visibility, Show stereotypes, Show all attributes, Show all operations, Show all aggregations. Capsule Show all ports. Protocol Show all in signals, Show all out signals (vezi figura 11.8).
Figura 11.8 Options
127
Adaugarea unui caz de utilizare

Pentru a aduga un caz de utilizare, procedai n felul urmtor: 1. Expandai n browser Use Case View i executai dublu click pe Main.
Remarc. Se afieaz fereastra numit Use Case View/ Main. Asigurai-v c este activ (vezi figura 11.9).
Figura 11.9 Fereastra Main a Use Case View
2. Din cutia cu instrumente alegei Text (ABC). Mutnd cursorul mouse-ului n diagram, acesta se transform n + (vezi figura 11.9). 3. Apsai butonul stng i tragei, formnd un dreptunghi. Scriei n el descrierea aplicaiei (cazului) (vezi figura 11.9).
Remarc. Putei ataa fiiere la acest model, utiliznd tab-ul Files care apare n dialogul specificaiei.
128
Figura 11.10 Crearea unui caz de utilizare
Pentru a crea un caz de utilizare, asigurai-v c Use Case Diagram este activ, dup care: 1. Selectai instrumentul Use Case (vezi figura 11.10). 2. Executai click n diagram.
Remarc. Se afieaz un element de caz de utilizare pe care l putei redenumi.
3. Executai dublu click pe cazul de utilizare nou aprut.
Remarc. Se afieaz Class Specification for... (numele cazului) (vezi figura 11.11).
129
Figura 11.11 Fereastra Class Specification for ...
4. n fereastra Documentation descriei scenariul, aa cum a fost el definit de dumneavoastr n UML.
130
Crearea claselor i capsulelor

n timp ce Clasele reprezint containere de informaii, Capsulele simuleaz anumite comportamente n cadrul sistemului. Acestea din urm sunt uniti cu un comportament concurenial (simuleaz activiti care se deruleaz n paralel). Prin combinarea capsulelor i claselor se obin sisteme complexe active n RRRT. Pentru a crea o clas/ capsul parcurgei urmtorii pai: 1. Deschidei Class Diagram: Logical View/ Main (vezi figura 11.12).
Figura 11.12 Crearea unei capsule
2. Selectai instrumentul Class/ Capsule (vezi figura 11.12). 3. Mutai mouse-ul n diagram i executai click. Redenumii elementul creat (vezi figura 11.12). 4. Adugai apoi asocierile i atributele corespunztoare.
131
12
Visual Paradigm for the Unified Modeling Language mediu complet de dezvoltare UML. Prezentarea principalelor faciliti. Aplicaii
n acest capitol: Prezentarea general a mediului de dezvoltare Visual Paradigm pentru UML Interfaa cu utilizatorul Adugarea unui caz de utilizare Descrierea cazurilor de utilizare Ierarhizarea cazurilor de utilizare n funcie de prioriti Generarea diagramelor de secven sistem pentru cazurile de utilizare Crearea claselor i a diagramelor de clase Diagramele de secven Diagramele de colaborare
n acest capitol vom prezenta, pe scurt, un alt mediu de dezvoltare creat pentru utilizarea limbajului UML i anume Visual Paradigm for the Unified Modeling Language. Acest mediu a fost creat de firma Visual Paradigm pentru proiectarea unor modele orientate obiect de sisteme informatice i a generrii, n final, a codului corespunztor n limbajul Java.
132
Prezentarea general a mediului Visual Paradigm for the Unified Modeling Language
recunoscut ca un limbaj de modelare grafic bazat pe UML, destinat realizrii sistemelor software orientate obiect. UML asigur att proiectarea ct i construirea sistemelor informatice, fiind capabil s furnizeze totodat ntreaga documentare a sistemelor realizate. Sunt disponibile toate diagramele UML, att cele statice ct i cele dinamice i funcionale, mediul Visual Paradigm facilitnd crearea i ntreinerea lor n cele mai mici detalii. n final, codul Java generat permite proiectantului trecerea fireasc la programare n vederea finalizrii aplicaiei. Este posibil i generarea invers a diagramelor pornind de la cod (reverse engineering). Pentru a utiliza VP-UML avei nevoie de un calculator PC compatibil IBM dotat cel puin cu un procesor Pentium III la 400 MHz i avnd o memorie RAM recomandat de minimum 128 MB, spaiul minim disponibil pe hard disc fiind de 220 MB. VP-UML ruleaz cu toate sistemele de operare MS Windows moderne, cu alte cuvinte 98, ME, NT, 2000, XP. Demararea unei sesiuni de lucru necesit accesul utilizatorului la Internet. Exemplele care urmeaz au fost realizate pe un calculator Pentium IV dotat cu sistemul de operare Windows XP, avnd o licen de utilizare a Visual Paradigm for the Unified Modeling Language versiunea 3.2 obinut printr-un Program de Parteneriat Academic ncheiat ntre Universitatea Petrol-Gaze din Ploieti i firma Visual Paradigm.
Visual Paradigm for the Unified Modeling Language (VP-UML) este
Interfaa cu utilizatorul
Visual Paradigm for Unified Modeling Language dispune de o interfa cu utilizatorul extrem de simpl i sugestiv. Fereastra principal (vezi figura 12.1) se compune din urmtoarele elemente: Bara standard; Arborele pentru diagrame; Panoul de proprieti; Bara de instrumente.
133
Figura 12.1 Fereastra principal a VP-UML
Bara standard
Bara standard este bara meniului principal File Edit View Code Option Tools Window Help care rmne vizibil pentru toate vederile i diagramele (vezi figura 12.2) i care are semnificaiile obinuite.
Figura 12.2 Bara standard a VP-UML
134
Arborele pentru diagrame

Arborele pentru diagrame apare n partea stng a ecranului i este vizualizat la apsarea tag-ului Diagram Tree (vezi figura 12.1). El conine, printre altele, tipurile de diagrame UML cunoscute: Use Case Diagram (diagrama cazurilor de
utilizare), Class Diagram (diagrama de clase), Sequence Diagram (diagrama de secven), Collaboration Diagram (diagrama de colaborare), State Diagram (diagrama de stare), Activity Diagram (diagrama de activitate), Component Diagram (diagrama de componente), Deployment Diagram (diagrama de desfurare) vezi figura 12.3.
Arborele pentru diagrame este legat la proiectul construit de utilizator i va conine toate diagramele acestuia. n figura 12.3, numele proiectului este Untitled.
Observaie. n partea dreapt a ecranului, se afieaz la nceput o fereastr care faciliteaz crearea oricrei diagrame prin executarea unui click pe link-ul respectiv (vezi figura 12.4).
Figura 12.3 Arborele de acces la diagramele UML
135
Figura 12.4 Fereastra de creare a diagramelor UML
Acelai lucru se poate obine executnd click pe icon-urile situate n partea superioar a panoului principal (vezi figura 12.5).
Figura 12.5 Icon-urile de creare a diagramelor UML
136
Tree View i Class Repository View (vezi figura 12.6).
Revenind n partea stng a ecranului, se mai observ nc dou tag-uri: Model
Figura 12.6 Tag-urile Diagram Tree, Model Tree i Class Repository View
Tag-ul Model Tree View vizualizeaz elementele modelului n cadrul proiectului, iar tag-ul Class Repository View vizualizeaz toate clasele proiectului.
Panoul de proprieti
Panoul de proprieti este situat n partea stng inferioar a ecranului (vezi figura 12.7). Exist patru pagini asociate panoului de proprieti: Pagina de proprieti (Property), Pagina de vizionare nainte de apariie (Preview), Pagina de documentare (Documentation) i Pagina de vizulizare a elementului (Element Viewer) - vezi figura 12.7.
Figura 12.7 Panoul de proprieti
1. Pagina de proprieti (Property) Fiecare diagram i element din diagram au proprietile lor. Pagina de proprieti v permite s vedei i s editai aceste proprieti. 2. Pagina de vizionare naintea apariiei (Preview) Pagina de preview, cunoscut i ca Diagram Monitor, prezint o vedere de ansamblu a diagramei curent selectate. Putei accesa rapid orice parte a diagramei, trgnd dreptunghiul de ncadrare a acestei pri. De asemenea, acest monitor v permite s navigai pe ntreaga diagram atunci cnd aceasta este prea larg i nu ncape n ntregime n fereastr.
137
3. Pagina de documentare (Documentation) permite utilizatorului s introduc o descriere a diagramei sau a unui element al su. 4. Pagina de vizualizare a elementului (Element Viewer) afieaz informaii de detaliu cu privire la elementul selectat din diagram. De exemplu, putei vedea atributele i operaiile clasei, fr a fi obligai s deschidei caseta de dialog a specificaiei clasei respective.
Bara de instrumente
n latura stng a fiecrei diagrame se afl o bar de instrumente care servesc la construcia diagramei (vezi figura 12.8). Exist dou proprieti speciale ale barei de instrumente: Grupul de butoane (Button Group) i Bara care defileaz (Scrollable Toolbar). Grupul de butoane (Button Group). Bara de instrumente grupeaz cteva instrumente similare prin natura lor. De exemplu, n bara din figura 12.8 ataat diagramelor de clase, Package i Subsystem sunt grupate ntr-un singur buton marcat cu un mic triunghi n colul din dreapta. Pentru a vedea lista obiectelor grupate sub aceast imagine, se execut click pe triunghi sau se execut click pe buton i se ine apsat pn cnd se afieaz aceast list.
Figura 12.8 Bara de instrumente pentru diagrama de clase
138
Bara care defileaz (Scrollable Toolbar). Dac ai redimensionat fereastra diagramei astfel nct o parte din bara de instrumente nu mai este vizibil, apar un buton Up i un buton Down, pe care putei executa click astfel nct bara s defileze pentru a putea s apar butoanele ascunse.
Adugarea unui caz de utilizare

Pentru a aduga un caz de utilizare, procedai n felul urmtor: 1. Executai click pe Create Use Case Diagram n panoul din dreapta (vezi figura 12.4), sau executai click pe icon-ul Create Use Case Diagram din partea superioar (vezi figura 12.5), sau executai click dreapta pe Use Case Diagram n arborele de diagrame (vezi figura 12.3); apoi executai click pe Create Use Case Diagram n fereastra care va apare alturat.
Remarci: Se deschide astfel un spaiu de lucru pentru a crea cazul de utilizare dorit. Acelai spaiu se poate deschide direct din meniul principal (vezi figura 12.2), dac executai click pe File, apoi pe New Diagram i apoi pe New Use Case Diagram n fereastra care va apare n urma acestor execuii.
2. Utiliznd bara de instrumente din stnga spaiului de lucru, alegei icon-ul Actor, executai click pe acesta, apoi mutai cursorul mouse-ului n spaiul de lucru i executai click acolo unde dorii s plasai actorul. Modificai numele acestuia nscriind numele dorit de dumneavoastr (de exemplu Navigator). 3. Executai click pe icon-ul Use Case din bara de instrumente, apoi mutai cursorul mouse-ului n spaiul de lucru i executai click acolo unde dorii s amplasai cazul de utilizare. Redenumii-l (de exemplu, Cautarea lucrarilor), apoi executai click n afara spaiului de scriere, oriunde n diagram.
Remarc. Apare ovalul caracteristic notaiei UML pentru cazuri de utilizare. Remarc. Elementul nou creat apare n arborele de diagrame, la diagrama Use Case Diagram1 vezi figura 12.9.
Redimensionai figura astfel nct s cuprind ntreaga denumire a cazului (vezi figura 12.10).
139
Figura 12.9 Crearea unui actor
Figura 12.10 Crearea asocierii ntre un caz de utilizare i un actor
140
4. Pentru a crea o asociere ntre cazul de utilizare nou creat i actor, aezei mouse-ul deasupra cazului de utilizare, pn cnd apar n jurul su o serie conexiuni posibile. Alegei pe aceea care exprim o asociere cu un actor, executai click, inei apsat i ndreptai mouse-ul spre actorul numit de noi Navigator pn cnd imaginea actorului se suprapune cu
acesta. Liberai butonul mouse-ului. Se creeaz asocierea dorit (vezi figura 12.10). 5. Creai, n acelai mod, cazul de utilizare Gestionarea cosului asociindu-l navigatorului. 6. Pentru a exprima faptul c elementul Gestiunea cosului extinde Cautarea lucrrilor, mutai mouse-ul pe Cautarea lucrrilor i alegei din mulimea icon-urilor care nconjoar acest caz de utilizare pe aceea care exprim o extensie (marcat cu E). Executai click pe aceasta, inei apsat butonul mouse-ului i tragei spre cazul de utilizare Gestiunea cosului pn cnd imaginea care apare se suprapune peste acest caz. Eliberai butonul mouse-ului.
Remarc. Observai extinderea nou creat conform sintaxei limbajului UML. Acelai lucru este marcat n arborele de diagrame n dreptul Use Case Diagram1(vezi figura 12.11). Remarc. Att cazul de utilizare ct i asocierea, s-au adugat n structura arborelui de diagrame, n dreptul Use Case Diagram1.
Figura 12.11 Extensia cazurilor de utilizare
Descrierea cazurilor de utilizare

VP-UML ofer o facilitate remarcabil de a introduce o descriere pentru fiecare caz de utilizare creat. n acest scop, se execut click dreapta pe cazul de utilizare respectiv, n diagram. Se execut click pe Open Specification n meniul pop-up care apare. Caseta respectiv de dialog conine proprieti ce pot fi completate, precum
141
nume, prioritate, sau stereotip. Se activeaz tag-ul Use Case Description ... Apare o nou caset, avnd rubricile: nume, cazul de utilizare superior, scurt descriere a cazului, precondiii, postcondiii i fluxul evenimentelor avnd dou rubrici semnalul de intrare de la actor i rspunsul sistemului (vezi figura
Remarc. Observai asemnarea cu ceea ce noi am numit fia-tip a cazului de utilizare (vezi capitolul 4). Putem completa rubricile scurt descriere, precondiii i postcondiii cu textul nscris n fia-tip a cazului de utilizare respectiv. Se pot introduce noi rubrici n aceast fi, de exemplu actorul principal, apsnd pe butonul Add Item, sau se pot terge altele pe care le considerai nesemnificative, apsnd pe butonul Remove Item (vezi figura 12.14).
12.14).
Figura 12.14 Descrierea cazurilor de utilizare
Ierarhizarea cazurilor de utilizare n funcie de prioriti

Putem acorda prioriti cazurilor de utilizare construite cu VP-UML, iar dup aceea le putem ordona n funcie de prioritile acordate. Aceast facilitate ne permite s obinem o planificare a realizrii cazurilor, la fel cum am procedat n cadrul paragrafului Clasamentul cazurilor de utilizare i planificarea proiectului (vezi capitolul 2).
142
Procedura de ierarhizare a cazurilor de utilizare n funcie de prioriti este prezentat n continuare. 1. Executai click dreapta pe un spaiu liber din diagrama cazurilor de utilizare.
Remarc. Se afieaz un meniu pop-up (vezi figura 12.15).
Figura 12.15 Meniul popup de selectare a ierarhizrii cazurilor de utilizare
2. Executai click pe Use Case Scheduling ...
Remarci: Se afieaz o caset de dialog n care sunt trecute toate cazurile de utilizare care apar n diagram. Dac executai click pe o celul, n dreptul unui caz, pe coloana intitulat Rank, avei posibilitatea de a acorda acelui caz una din prioritile: sczut (Low), medie (Medium) sau nalt (High). n coloana intitulat Justification putei trece motivarea prioritii acordate (vezi figura 12.16). Apsnd pe Rank n header, vei obine n final o sortare n ordinea prioritilor acordate (triunghiul cu vrful n jos), sau n ordine invers prioritilor acordate (triunghiul cu vrful n sus).
143
Figura 12.16 Caseta de dialog pentru ierarhizarea cazurilor de utilizare
Generarea diagramelor de secven sistem pentru cazurile de utilizare

Pentru a genera o diagram de secven sistem pentru un caz de utilizare aplicai procedura descris n cele ce urmeaz: 1. Executai click dreapta pe cazul de utilizare. 2. Executai click pe Generate Sequence Diagram.
Remarc. Se afieaz un menu pop-up. Remarc. Se afieaz o nou diagram de secven, la nivel sistem, n concordan cu fluxul de evenimente definit n descrierea cazului de utilizare.
144
Crearea claselor i a diagramelor de clase

Crearea unei diagrame de clase vid i adugarea unei clase n interiorul diagramei
Pentru a crea o clas cu VP-UML, este necesar ca mai nti s generm o diagram de clase vid. n acest scop, se procedeaz n mod similar cu crearea unei diagrame vide a cazurilor de utilizare, adic n felul urmtor: 1. Executai click pe Create Class Diagram n panoul din dreapta (vezi figura 12.4), sau executai click pe icon-ul Create Class Diagram din partea superioar (vezi figura 12.5), sau executai click dreapta pe Class Diagram n arborele de diagrame (vezi figura 12.3) i apoi executai click pe Create Class Diagram sau pe Create Class Diagram with real time code generation n subfereastra care va apare alturat.
2. Utiliznd bara de instrumente din stnga spaiului de lucru astfel creat, alegei icon-ul Class, executai click pe acesta, apoi mutai cursorul mouse-ului n spaiul de lucru i executai click acolo unde dorii s plasai clasa. Modificai numele acesteia nscriind numele dorit de dumneavoastr (de exemplu Carte).
Remarc: Elementul nou creat apare n arborele de diagrame, la diagrama Class Diagram1 vezi figura 12.18.
Remarci: Se deschide astfel un spaiu de lucru pentru a crea diagrama de clase dorit. Acelai spaiu se poate deschide direct din meniul principal (vezi figura 12.2), dac executai click pe File, apoi pe New Diagram iar apoi pe New Class Diagram n fereastra care va apare n urma acestor execuii.
Adugarea atributelor
Iat cum procedm pentru a aduga un atribut n clasa Carte creat anterior:
Metoda 1:
1. Executai click dreapta pe clasa Carte. 2. Executai click pe New Attribute. Este adugat un atribut cu numele generic attribute (de tip private) n interiorul clasei. Numele l putei modifica ulterior executnd dublu click pe acesta. 3. Ctrl+Enter finalizeaz aceast operaie.
Remarc. Apare un menu pop-up.
145
Metoda 2:
1. Se execut click dreapta pe clas n diagram (se afieaz acelai meniu) iar apoi executai click pe Open Specification. 2. n caseta de dialog care apare activai tag-ul Attributes (apare tabelul atributelor). 3. Efectuai click pe butonul Add. (se nscrie n tabel o nou linie de atribut cu nume generic attribute). 4. Modificai numele (Name), de exemplu titlu, apoi tipul (Type), de exemplu char, apoi vizibilitatea (Visibility), de exemplu package, apoi valoarea iniial (Initial Value), de exemplu, xxx. Completai, dac este cazul, i celelalte rubrici, de exemplu Documentation nscriind semnificaia acestui atribut n cadrul clasei.
Remarc. Apare fereastra intitulat Attribute Specification pentru acest atribut.
Crearea relaiilor ntre clase

Iat cum procedm ca pentru clasele Carte, Cos i LinieCos, create anterior, s introducem relaiile corespunztoare cazului de utilizare Gestionarea coului. n acest scop, vom utiliza interfaa centrului de resurse (resource centric interface) compus din imagini grafice care apar n jurul fiecrei clase n momentul n care cursorul mouse-ului se afl deasupra clasei respective. Procedura pe care trebuie s-o urmai este prezentat n cele ce urmeaz: 1. Aezai mouse-ul deasupra clasei LinieCos n aa fel nct s apar resursele. Alegei icon-ul corespunztor asocierii, executai click pe acesta i tragei spre clasa Carte pn se suprapune peste aceasta. 2. Eliberai butonul mouse-ului observnd crearea asocierii. 3. Deplasai mouse-ul deasupra clasei Cos, alegei resursa corespunztoare compunerii, executai click pe icon i tragei spre LinieCos pn cnd clasa care apare se suprapune peste aceasta. 4. Eliberai butonul mouse-ului. 5. Pentru a aduga caracteristici primei asocieri, ntre LinieCos i Carte, executai click dreapta pe linia de asociere. 6. Deplasai mouse-ul spre Role B (Carte).
Remarci: Apare Remarc. Apare o fereastr care conine caracteristicile asocierii. Remarc. Observai crearea compunerii cu rombul plin spre clasa Cos i sgeata spre LinieCos.
146
7. Pentru Multiplicity se alege opiunea 1 o singur carte pentru fiecare linie a coului (vezi figura 12.20).
selectat aceast opiune.
o subfereastr care conine urmtoarele rubrici: Navigate, Multiplicity, Visibility, Agregation Kind, Edit Role B Role Name ... Captul dinspre Carte al asocierii este navigabil, astfel nct rmne
Figura 12.20 Adugarea caracteristicilor unei asocieri
8. Executai click pe Edit Role B Role Name ...
Remarc. Visibility i Agregation Kind rmn nespecificate. Remarc. Apare o caset n care trecem numele b pentru acest rol.
9. Mutai mouse-ul pe Role A (LinieCos) i completai, n acelai mod, Multiplicity cu 0..* (notaia UML pentru mai multe obiecte sau nici unul). Anulai navigabilitatea spre acest rol (apare o sgeat la captul opus). Dai acestui rol numele a. 10. Apsai pe Open Specification i numii aceast asociere refer.
Adugarea operaiilor
Pentru a aduga o operaie unei clase n VP-UML, urmai procedura descris n continuare.
Metoda 1
1. Executai click dreapta pe clasa respectiv n diagrama de clase. 2. Executai click pe New Operation. 3. Redenumii operaia. 4. Activai Ctrl+Enter.
Remarc. Apare acelai menu pop-up cunoscut de la adugarea atributelor. Remarc. Este adugat o nou operaie numit +operation().
147
Metoda 2
1. Analog cu crearea atributelor, efectuai pasul 1 de la Metoda 1. 2. Deschidei Open Specification i apoi activai tag-ul Operation.
3. Apsai butonului Add.
Remarc. Se afieaz tabelul operaiilor n care sunt puse n eviden caracteristicile: numele (Name); clasa (Classifier); vizibilitatea (Visibility); tipul informaiei returnate dup executarea operaiei (Return type). Remarci: Se afieaz cutia de dialog Operation Specification. Activai tag-ul General, dup care putei edita urmtoarele proprieti: nume (Name), stereotip (Stereotype), tipul de retur (Return Type), vizibilitate (Visibility), Scope, Documentation (apsarea butonului OK definitiveaz opiunile dumneavoastr). Activai tag-ul Parameter. Se afieaz tabloul parametrilor. Adugarea unui parametru se realizarea prin apsarea butonului Add. Se afieaz cutia de dialog Parameter Specification cu urmtoarele proprieti: nume (Name), stereotip (Stereotype), tip (Type), direcie (Direction), valoare implicit (Default Value) i Documentation. Dup completarea acestora se execut click pe butonul OK pentru a nchide Parameter Specification.
Crearea unei diagrame de secven vid i adugarea obiectelor i mesajelor n interiorul diagramei
Primul pas n crearea unei diagrame de secven cu VP-UML, este generarea unei diagrame de secven vide. n acest scop, se procedeaz n mod similar cu crearea unei diagrame vide a cazurilor de utilizare i a claselor, dup cum urmeaz: 1. Executai click pe Create Sequence Diagram n panoul din dreapta (vezi figura 12.4), sau executai click pe icon-ul Create Sequence Diagram din partea superioar (vezi figura 12.5), sau executai click dreapta pe Sequence Diagram n arborele de diagrame (vezi figura 12.3) i apoi executai click pe Create Sequence Diagram n subfereastra care va apare alturat.
148
2. Utiliznd bara de instrumente din stnga spaiului de lucru astfel creat, alegei icon-ul Actor, executai click pe acesta, apoi mutai cursorul mouse-ului n spaiul de lucru i executai click acolo unde dorii s plasai linia de via a obiectului. Modificai numele acestuia nscriind numele dorit de dumneavoastr (de exemplu Navigator).
Remarci: Se deschide astfel un spaiu de lucru pentru a crea diagrama de secven dorit. Acelai spaiu se poate deschide direct din meniul principal (vezi figura 12.2), dac executai click pe File, apoi pe New Diagram i apoi pe New Sequence Diagram n fereastra care va apare n urma acestor execuii.
3. Procedai n acelai mod cu icon-ul Object/Classifier Role, generndacest obiect n dreapta primului, la o oarecare distan. Modificai-i numele (de exemplu RezultCaut). 4. Cutai n bara de instrumente icon-ul Message, executai click pe acesta, apoi deplasai cursorul mouse-ului n diagram; executai click pe bara de focus a Navigatorului i tragei mouse-ul pn ntlnete linia de via a RezultCaut. Eliberai butonul mouse-ului. Denumii acest mesaj puneInCos. Dup ce ai scris numele mesajului executai click pe un loc liber n diagram.
Remarc. Rezultatul ar trebui s fie identic cu cel prezentat n figura 12.28.
Remarc. Elementul nou creat apare n arborele de diagrame, la diagrama Sequence Diagram nou creat vezi figura 12.17.
Figura 12.28 Rezultatul nscrierii n diagrama de secven a primului mesaj
149
Necesitatea i obiectivele UML

Odat obiectul creat, i putem ataa acestuia un stereotip care s ne arate c obiectul este o instan a unei clase rezultate din analiz, cu alte cuvinte face parte din categoria grani (boundary), control (control) sau entitate (entity). Procedura este prezentat n cele ce urmeaz. 1. Executai click dreapta pe obiect (de exemplu, pe RezultCaut). n fereastra popup care apare executai click pe Stereotype. Se ivete o subfereastr n dreapta din care alegei, de exemplu, boundary (vezi figura 12.29). 2. Creai obiectul ControlCos, n dreapta ultimului, atandu-i stereotipul control. 3. Trasai pe diagram un mesaj, de la RezultCaut ctre ControlCos, pe care l denumii adaugaLinie.
Figura 12.29 Alegerea stereotipului pentru un obiect
150
Reprezentarea n diagrama de secven a crerii unui obiect ca rezultat al recepionrii unui mesaj
Iat cum reprezentm acum n diagram, crearea obiectului de tip entitate numit Cos. Procedura este prezentat n cele ce urmeaz. 1. Creai mai nti obiectul Cos, n dreapta ultimului obiect existent i ataai-i stereotipul entity. 2. Identificai n bara de instrumente icon-ul Create Message, executai click pe focus-ul obiectului ControlCos i tragei pn la linia de via a obiectului Cos. Acesta coboar n diagram i noul tip de mesaj, cu o sgeat alb, se oprete n dreptunghiul care l reprezint, sugernd crearea. Denumii acest mesaj create (vezi figura 12.30).
Figura 12.30 Reprezentarea creerii unui obiect n diagrama de secven
151
Diagramele de colaborare
Crearea unei diagrame de colaborare vid i adugarea obiectelor n interiorul diagramei

Primul pas n crearea unei diagrame de colaborare cu VP-UML, este, aa cum neam obinuit, generarea unei diagrame de colaborare vide (a se vedea crearea unei diagrame vide a cazurilor de utilizare, claselor i diagramelor de secven). Procedura de creare a unei diagrame de colaborare i de adugare a obiectelor n interiorul diagramei este prezentat n cele ce urmeaz. 1. Executai click pe Create Collaboration Diagram n panoul din dreapta (vezi figura 12.4), sau executai click pe icon-ul Create Collaboration Diagram din partea superioar (vezi figura 12.4), sau executai click dreapta pe Collaboration Diagram n arborele de diagrame (vezi figura 12.3) i apoi executai click pe Create Collaboration Diagram n subfereastra care va apare alturat. Se deschide astfel un spaiu de lucru pentru a crea diagrama de colaborare dorit.
2. Utiliznd bara de instrumente din stnga spaiului de lucru astfel creat, alegei icon-ul Actor, executai click pe acesta, apoi mutai cursorul mouse-ului n spaiul de lucru i executai click acolo unde dorii s plasai obiectul. Modificai numele acestuia nscriind numele dorit de dumneavoastr (de exemplu Navigator). 3. Procedai n acelai mod cu icon-ul Object, generndu-l sub primul, la o oarecare distan. Modificai-i numele (de exemplu, RezultCaut). 4. Executai click dreapta pe obiectul nou creat i n menuul popup care apare activai Stereotype. Alegei din list boundary i facei click pe acesta. Remarc. Icon-ul care reprezint obiectul creat se modific n conformitate su standardul UML pentru obiectele de tip grani (vezi figura 12.32).
Remarc. Elementul nou creat apare n arborele de diagrame, la diagrama Collaboration Diagram nou creat vezi figura 12.17.
Remarc. Acelai spaiu se poate deschide direct din menuul principal (vezi figura 12.2), dac executai click pe File, apoi pe New Diagram i apoi pe New Collaboration Diagram n fereastra care va apare n urma acestor execuii.
152
Figura 12.32 Modificarea obiectului de tip grani RezultCaut n conformitate su standardul UML, n diagrama de colaborare VP-UML
Adugarea legturilor ntre obiecte

Pentru crearea unei legturi ntre obiecte, aplicai procedura descris n continuare. 1. Identificai n bara de instrumente icon-ul Link i executai click pe acesta; iar apoi deplasai cursorul mouse-ului n diagram. Executai click pe Navigator i tragei mouse-ul pn ntlnete obiectul RezultCaut. Eliberai butonul mouse-ului. Se creeaz o legtur ntre Navigator i RezultCaut (vezi figura 12.33).
153
Figura 12.33 Crearea unei legturi ntre Navigator i RezultCaut
Remarc. Se observ n stnga, n arborele de diagrame, apariia obiectelor i legturii create.
Adugarea mesajelor n interiorul diagramei

Pentru adugarea mesajelor n interiorul diagramei, aplicai procedura decris n continuare. 1. Identificai n bara de instrumente icon-ul Message To, executai click pe acesta, iar apoi deplasai cursorul mouse-ului n diagram i executai click pe legtura nou creat ntre Navigator i RezultCaut. Se genereaz o sgeat, paralel cu legtura, ndreptat spre RezultCaut. nscriei numele mesajului, de exemplu puneInCos.
Remarc. Se observ n stnga, n arborele de diagrame, apariia noului mesaj (vezi figura 12.34). Observaie. Pentru a genera un mesaj ndreptat n sens invers, adic, n cazul nostru, de la RezultCaut spre Navigator, trebuie s selectai din bara de instrumente icon-ul Message From. Procedura de generare este identic aceleia descris mai sus.
154
Figura 12.34 Crearea unui mesaj pe legtura ntre Navigator i RezultCaut
Crearea unei diagrame de activiti vid i adugarea obiectelor, legturilor i mesajelor n interiorul diagramei
Primul pas n crearea unei diagrame de activiti cu VP-UML, este, aadar, generarea unei diagrame de activiti vide. n acest scop, se procedeaz n mod similar cu crearea unei diagrame vide a cazurilor de utilizare, claselor, diagramelor de secven i diagramelor de colaborare, dup cum urmeaz: 1. Executai click pe Create Activity Diagram n panoul din dreapta (vezi figura 12.4), sau executai click pe icon-ul Create Activity Diagram din partea superioar (vezi figura 12.5), sau executai click dreapta pe Activity Diagram n arborele de diagrame (vezi figura 12.32) i apoi executai click pe Create Activity Diagram n subfereastra care va apare alturat. Se deschide astfel un spaiu de lucru pentru a crea diagrama de activiti dorit.
Remarc. Acelai spaiu se poate deschide direct din meniul principal (vezi figura 12.2), dac executai click pe File, apoi pe New Diagram i apoi pe New Activity Diagram n fereastra care va apare n urma acestor execuii.
155
2. Utiliznd bara de instrumente din stnga spaiului de lucru astfel creat, alegei icon-ul Initial State, executai click pe acesta, apoi mutai cursorul mouse-ului n spaiul de lucru i executai click acolo unde dorii s plasai obiectul.
Remarc. Elementul nou creat apare n arborele de diagrame, la diagrama Activity Diagram nou creat vezi figura 12.36.
Figura 12.36 Crearea strii iniiale n diagrama de activiti
3. Executai click pe obiectul nou creat (se afieaz interfaa centrului de resurse (resource centric interface) al acestuia). Apsai pe icon-ul Aciune (Action State). Apare o aciune, la o oarecare distan; tragei-o la locul dorit n diagram. Modificai-i numele de exemplu, Primirea comenzii vezi figura 12.37. 4. Executai click dreapta pe obiectul nou creat i din centrul de resurse care apare alegei Synchronization bar; tragei apoi aceast bar de sincronizare sub Primirea comenzii. 5. Executai click pe obiectul Transition n caseta cu instrumente. Tragei cu mouse-ul tranziia de la Primirea comenzii ctre Synchronization bar (vezi figura 12.38).
Remarc. Synchronization bar apare n arborele de diagrame din stnga (vezi figura 12.38).
156
Figura 12.37 Crearea aciunii Primirea comenzii n diagrama de activiti
Figura 12.38 Inserarea barei de sincronizare n diagrama de activiti
Crearea culoarelor n interiorul diagramei de activiti

Pentru a aduga un culoar de separare a activitilor n diagrama nou creat, procedai dup cum urmeaz:
157
1. Apsai pe butonul Swimlane din caseta cu instrumente, iar apoi executai click n locaia dorit din diagram. Apare un culoar, care se redenumete (de exemplu, Serviciul Clieni) vezi figura 12.39.
Observaie. Pentru ca obiectele create s apar n interiorul culoarului, acesta trebuie creat la nceput, dup generarea diagramei de activiti vid. n caz contrar, acestea trebuie trase n interiorul culoarului.
Figura 12.39 Inseria unui culoar n diagrama de activiti
Diagramele de stare
Crearea unei diagrame de stare vid i adugarea obiectelor, legturilor i mesajelor n interiorul diagramei
Primul pas n crearea unei diagrame de stare cu VP-UML, este generarea unei diagrame de stare vide. n acest scop, se procedeaz n mod similar cu crearea unei diagrame vide a cazurilor de utilizare, claselor, diagramelor de secven, diagramelor de colaborare i diagramelor de activiti, dup cum urmeaz:
158
1. Executai click pe Create State Diagram n panoul din dreapta (vezi figura 12.4), sau executai click pe icon-ul Create State Diagram din partea superioar (vezi figura 12.5), sau executai click dreapta pe State Diagram n arborele de diagrame (vezi figura 12.3) i apoi executai click pe Create State Diagram n subfereastra care va apare alturat. Se deschide un spaiu de lucru pentru a crea diagrama de stare dorit.
Remarc. Acelai spaiu se poate deschide direct din meniul principal (vezi figura 12.1), dac executai click pe File, apoi pe New Diagram i apoi pe New State Diagram n fereastra care va apare n urma acestor execuii.
2. Utiliznd bara de instrumente din stnga spaiului de lucru astfel creat, alegei icon-ul Initial State, executai click pe acesta, apoi mutai cursorul mouse-ului n spaiul de lucru i executai click acolo unde dorii s plasai obiectul. Redenumii-l Efectuarea comenzii.
Remarc. Elementul nou creat apare n arborele de diagrame, la diagrama State Diagram nou creat (vezi figura 12.41).
Figura 12.41 Introducerea strii iniiale n diagrama de stare
3. Executai click pe icon-ul de stare (State), apoi mutai mouse-ul n interiorul diagramei i facei click la o oarecare distan de Initial State, la dreapta acesteia. Redenumii-o Stare Sistem. Executai click pe noua stare i mrii-i dimensiunea vertical pentru a apare ca un dreptunghi mai mare, alungit n jos (vezi figura 12.42). 4. Executai click pe obiectul Initial State (apare interfaa centrului de resurse (resource centric interface) al acestui obiect). Apsai pe icon-ul State. Apare o stare, la o oarecare distan; tragei-o spre dreapta, n interiorul strii Stare Sistem. Modificai-i apoi numele n Fisa client (stare 1) vezi figura 12.43. 5. Procedai ca la pasul 3 i inserai la dreapta o nou stare (global) pe care o redenumii Stare client. Alungii-o ca s semene cu Stare sistem.
159
160
Figura 12.42 Inseria unei stri n diagrama de stare
Figura 12.43 Inseria unei stri n interiorul altei stri, n diagrama de stare
6. Procedai ca la pasul 4, executai click pe obiectul Fisa client (stare 1) i utiliznd resource centric interface al acestuia, creai o nou stare pe care o tragei n interiorul Strii client. Redenumii-o Actualizare informatii despre client. Plasai apoi mouse-ul pe tranziia spre aceast nou stare, executai click dreapta deschiznd Open Specification i modificai numele tranziiei n trimis pentru completare. Diagrama ar trebui s arate acum ca n figura 12.44.
161
Figura 12.44 Tranziia spre starea clientului Actualizare informatii despre client, care completeaz Fisa client
7. Executai click pe icon-ul Transition, mutai mouse-ul peste Actualizare informatii despre client, apsai i tragei pn n interiorul Fisa client (stare 1).
Remarc. Se formeaz o nou tranziie pe care o numii fisa client completata (vezi figura 12.45).
Figura 12.45 Tranziia de rspuns fisa client completata
162
8. Executai click pe Fisa client (stare 1). Utiliznd resource centric interface al acesteia, creai o nou stare pe care o tragei n interiorul Strii client. Redenumii-o Actualizare informatii despre comanda. Plasai apoi
mouse-ul pe tranziia spre aceast nou stare, executai click dreapta deschiznd Open Specification i modificai numele tranziiei n trimis pentru completare. Executai click pe icon-ul Transition, mutai mouse-ul peste Actualizare informatii despre comanda, apsai i tragei pn n interiorul Fisa comanda(stare 2).
Remarc. Se formeaz o nou tranziie pe care o numii fisa comanda completata (vezi figura 12.46).
Figura 12.46 Strile 1 i 2 completate cu tranziiile aferente
9. Introducei n Stare sistem o nou stare numit Lansare comanda (stare 3) generat printr-o tranziie de la Fisa comanda (stare 2). Generai apoi o nou stare numit Validare lansare comanda n interiorul Strii client, printr-o tranziie plecnd de la Lansare comanda (stare 3) i o tranziie rspuns numit lansare comanda validata plecnd de la Validare lansare comanda ctre Lansare comanda (stare 3). n final, trasai o tranziie de la Lansare comanda (stare 3) ctre un punct de ieire din diagram, executnd click pe resource centric interface al acestei ultime stri. Dac ai lucrat corect, diagrama dumneavoastr final ar trebui s arate ca n figura 12.47. ______________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________
163
Figura 12.47 Diagrama de stare VP-UML pentru efectuarea comenzii
Comentarii:
1. Diagrama de stare realizat cu VP-UML din figura 12.47 nu este altceva dect un alt mod de a reprezenta diagrama combinat stri-aciuni pentru efectuarea comenzii, ilustrat n figura 8.8 din capitolul 8. 2. ntr-adevr, observm c n figura 8.8 exist de fapt dou stri de baz: Starea sistem, n care exist o nlnuire logic ntre Fia client, Fia comand i Lansarea propriu-zis a comenzii i Starea client, care nu face dect s completeze, la nevoie, fiele respective cu informaiile corespunztoare i s valideze comanda. 3. Acest lucru ne permite s reprezentm circulaia informaiilor prin tranziii ntre aceste stri, ca n figura 12.47, urmnd ca dup atingerea strii de Lansare a comenzii cu comanda validat de client s nchidem diagrama. 4. Am ales special acest exemplu pentru a ilustra faptul c acelai proces poate fi reprezentat n mai multe feluri prin diagrame UML de diverse tipuri, care se completeaz reciproc i ne ajut la mai buna nelegere a comportamentului obiectelor n cadrul proiectului.
164
______________________________________________________________ _________________________________________________________________ _________________________________________________________________
Bibliografie
1. [BRJ] Booch Grady, Rumbaugh James, Jacobson Ivar Le guide de lutilizateur UML, Edition Eyrolles, 2000, pp.8-10 (trad.l.engl. The Unified Modeling Language User Guide, Addison-Wesley, 1998) 2. [Cockburn] Alistar Cockburn Writing Effective Use Cases, Addison Wesley, 2001 3. [Cook&Daniels] Steve Cook and John Daniels Designing Object Systems: Object-Oriented Modeling with Syntropy, Prentice Hall, 1994 4. [Davidescu] Niculae Dumitru Davidescu Proiectarea sistemelor informatice prin limbajul Unified Modeling Language (PSI 2) - Tratat, Editura ALL BECK, 2003 5. [Dumitrascu] Liviu Dumitrascu JavaScript, Editura Universitii din Ploieti, 2004 6. [Fowler&Scott] Martin Fowler et Kendall Scott Le tout en poche - UML, 2002, Campus Press, p.15 (trad.l.engl. UML Distilled, Second Edition, Addison-Wesley Longman, Inc., 2000) 7. [Fowler2] Martin Fowler UML 2.0, CampusPress, 2004, pp.181-189 (trad.l.engl. UML Distilled Third Edition, Addison Wesley, 2003) 8. [Fowler3] Fowler Martin Analysis Patterns: Reusable Object Models, Addison-Wesley, 1997 9. [GHJV] Gamma Erich, Helm Richards, Johnson Ralph and Vlissides John Design Patterns: Elements of Reusable Object-Oriented Software, AddisonWesley, 1995 10. [Gutu] Stelian Guu, Tehnologiile informaiei i comunicaiilor - Mijloace multimedia, Editura ILEX i Editura Universitii din Ploieti, 2001, ISBN 97399015-6-5, 272 pagini 11. [Gutu1] Stelian Guu, UML Limbaj de modelare unificat destinat managementului sistemelor complexe, n Sisteme informatice de management, Coordonatori L.Dumitracu i M.G.Petrescu, Editura Universitii din Ploieti, 2004, ISBN 973-7965-71-X, pp.37-68 12. [Halle] Von Halle, B Business Rules Applied: Building Better Systems Using the Business Rules Approach, Wiley, 2002 13. [Ionita] Anca Daniela Ioni Modelarea UML n ingineria sistemelor de programare, BIC ALL, 2003 14. [Jacobson] I.Jacobson The Unified Software Development Process, Addison Wesley, 1999 15. [JavaJ2EE] The J2EE 1.4 Tutorial http://Java.sun.com/J2ee/1.4/docs/tutorial/doc/index.html 16. [JavaWebServ] The Java Web Services Tutorial http://Java.sun.com/WebServices/docs/1.4/tutorial/doc/index.html
165
166
17. [JCJO] Ivar Jacobson, Magnus Christerson, Patrik Jonsson & Gunnar Overgaard Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992 18. [Larman] Larman Craig Applying UML and Patterns, Prentice Hall, 1998 19. [LuChi-kw] Dr.Lucas Chi-kwong Hui Introduction to object-oriented systems development, External Course Assessor, University of Hong Kong, 2003 20. [Martin&Odel] Martin James and Odel James J. Object-Oriented Methods: A Foundation (UML Edition), Prentice Hall, 1995 21. [Martin] Robert Celal Martin Designing Object-Oriented C++ Applications: Using the Booch Method, Prentice Hall, 1995 22. [Mayer] Bertrand Mayer Object-Oriented Software Construction, Prentice Hall, 1997 23. [Roques&Valle] Pascal Roques, Franck Valle UML en action: De lanalyse des besoins la conception en Java, Edition Eyrolles, Paris, 2000 et 2003 24. [Roques] Pascal Roques Les Chaiers du programmeur UML: Modliser un site e-commerce, Edition Eyrolles, 2002, pp.61-68 25. [Roques1] Pascal Roques UML 2 par la pratique. Etudes de cas et exercices corrigs, Editions Eyrolles, Paris, 2004, pag.220 26. [Rosenberg&Scott] Rosenberg, D and Scott, K Use Case Driven Object Modelling with UML: A Practical Approach, Reading, MA: Addison-Wesley, 1999 27. [RRRT] Rational Rose RealTime for Windows, pachet de programe comercializat de IBM, http:/www.downseek.com/download/ 19186.asp 28. [Sinan] Sinan Si Alhir Introduction UML, Edition OREILLY, Paris, 2004 29. [VP2.0Tut] Visual Paradigm for the Unified Modeling Language VP-UML 2.0 Tutorial, http://www.visual-paradigm.com 30. [VP3.0Not] Visual Paradigm for the Unified Modeling Language VP-UML 3.0 Users Notation, Copyright 1999-2003 by Visual Paradigm, http:/www.apache.org 31. [VP3.2IG] Visual Paradigm for UML 3.2 Installation Guide, Copyright 19992004 by Visual Paradigm, http:/www.apache.org Apache Software Foundation 32. [VP3.2QS] Visual Paradigm for UML 3.2 Quick Start Copyright 1999-2004 by Visual Paradigm, http:/www.apache.org Apache Software Foundation 33. [VP3.2UG] Visual Paradigm for UML 3.2 Users Guide, Copyright 1999-2004 by Visual Paradigm, http:/www.apache.org Apache Software Foundation 34. [Warmer&Kleppe] Jos Warmer and Anneke Kleppe The Object Constraint Language: Precise Modeling with UML, Addison-Wesley, 1998 35. [Wirfs-Brock] - Rebecca Wirfs-Brock, Brian Wilkerson and Lauren Wiener Designing Object-Oriented Software, Prentice Hall, 1990

Dumitrascu Analizasiproiectare

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Dumitrascu Analizasiproiectare

Încărcat de

Drepturi de autor:

Formate disponibile

Stelian Guu Gabriel Marcu

Liviu Dumitracu (coordonator) Liviu Ioni Bogdan Dumbrvescu

Analiza i proiectarea orientat obiect a sistemelor informatice cu UML

Editura Universitii din Ploieti 2005

Despre modelare, principii de modelare, limbaje de modelare

Analiza i proiectarea orientat obiect a sistemelor informatice cu UML

Lucrrile de specialitate menioneaz urmtoarele patru principii ale modelrii 1:

Analiza i proiectarea orientat obiect a sistemelor informatice cu UML

De ce un limbaj orientat obiect?

Metodologii de realizare a sistemelor informatice

Metoda SDLC (Systems Development Life Cycle)

Metoda SDLC iterativ

Analiza i proiectarea orientat obiect a sistemelor informatice cu UML

Proiectarea orientat obiect

Caracteristicile abordrii obiect

Analiza i proiectarea orientat obiect a sistemelor informatice cu UML

UML standard industrial de modelare obiect

Figura 1.1 Istoricul UML

Industrializare Standardizare OMG

Partenerii UML UML 0.91 UML 0.9 Unificarea Metodelor

Analiza i proiectarea orientat obiect a sistemelor informatice cu UML

06/1996: 10/1995: 10/1994:

Metoda unificat 0.8 Booch93+OMT-2

De la UML 1.0 la UML 1.1

De la UML 1.2 (i 1.1) la UML 1.3

De la UML 1.3 la UML 1.4

Analiza i proiectarea orientat obiect a sistemelor informatice cu UML

De la UML 1.4 la UML 1.5

Referitor la diagramele de clase: concepte eseniale

Referitor la diagramele de clase: concepte avansate

Diagramele de maini de stare

Figura 1.2 Diagrama UML. Cazuri de utilizare

Analiza i proiectarea orientat obiect a sistemelor informatice cu UML

Diagramele statice (sau structurale)

Figura 1.3 Diagrama de clase UML

Clasa A atribut1 operaie1() 1 0..*

Clasa B atribut2 atribut3 operaie2() operaie3()

software i arat cum se construiesc diagramele claselor detaliate.

Figura 1.4 Diagrama de obiecte UML

filiala1 : ntreprindere localitate = Braov printe copil

Analiza i proiectarea orientat obiect a sistemelor informatice cu UML

Georgescu : Angajat localitate = Braov

Figura 1.5 Diagrama de pachete UML

Diagramele de structuri compozite

Telecomand :Controlor :Generator

Analiza i proiectarea orientat obiect a sistemelor informatice cu UML

Figura 1.7 Diagrama de componen UML

<<Applet>> IOM <<Baza de date>> Clieni

Diagramele de componen sunt utilizate n cadrul capitolului 11.

Figura 1.8 Diagrama de desfurare UML

Server central Server Web

Diagramele de desfurare sunt utilizate n cadrul capitolului 11.

Diagramele dinamice (sau comportamentale)

Analiza i proiectarea orientat obiect a sistemelor informatice cu UML

Figura 1.9 Diagrama de activiti UML

Activ.2 Activ.1 Activ.3

Diagramele de activiti sunt tratate n cadrul capitolelor 8 i 12.

Figura 1.10 Diagrama de stare UML

Diagramele de stare sunt tratate n cadrul capitolelor 8 i 12.

Figura 1.11 Diagrama de secven UML

Analiza i proiectarea orientat obiect a sistemelor informatice cu UML

Figura 1.12 Diagrama de colaborare UML

1:m1 :Clasa A 4: :Actor 3: :Clasa B 2:m2

______________________________ _ _ _________________________________