Sunteți pe pagina 1din 166

Stelian Guţu Gabriel Marcu

Liviu Dumitraşcu (coordonator)

Liviu Ioniţă

Bogdan Dumbrăvescu

Analiza şi proiectarea orientată obiect a sistemelor informatice cu UML

Editura Universităţii din Ploieşti

2005

Analiza şi proiectarea orientată obiect a sistemelor informatice cu UML

1

Modelare şi UML

În acest capitol:

in f ormatice cu UML 1 Modelare ş i UML În acest capitol: Despre modelare, principii

Despre modelare, principii de modelare, limbaje de modelare

Metodologii de realizare a sistemelor informatice UML – standard industrial de modelare obiect Tipuri de diagrame UML

industrial de modelare obiect Tipuri de diagrame UML Despre modelare, principii de modelare, limbaje de modelare
industrial de modelare obiect Tipuri de diagrame UML Despre modelare, principii de modelare, limbaje de modelare
industrial de modelare obiect Tipuri de diagrame UML Despre modelare, principii de modelare, limbaje de modelare

Despre modelare, principii de modelare, limbaje de modelare

De cele mai multe ori, în viaţa de zi cu zi, avem de-a face cu modele. Astfel, atunci când 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 susţine o teorie sau a demonstra ceva. Celelalte caracteristici, ca de exemplu consumul de carburanţi, preţul sau costul întreţinerii, au fost neglijate cu bună ştiinţă pentru că nu erau relevante pentru teoria noastră. La fel, atunci când ne referim la cunoştinţe, prieteni sau, dimpotrivă duşmani, neglijăm, de cele mai multe ori, aspectul lor fizic şi ne referim la modelul lor psihologic sau comportamental verificat în relaţiile cu propria noastră persoană. În general, spunem că nu putem trece la a realiza ceva, fără 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

2 informaţionale ale activităţilor noastre în cele mai diverse domenii – producţie, servicii, comerţ, politică, administraţie. 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 esenţiale permiţând abordarea sa sistematică şi controlul pe parcursul execuţiei. 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 documentaţiei de proiectare.

Modelul este, prin urmare, o reprezentare abstractă a unui sistem, care permite planificarea, studiul, analiza, concepţia şi verificarea performanţelor sistemului înainte de realizarea sa propriu zisă, precum şi crearea documentaţiei de proiectare, facilitând totodată comunicarea între echipele de proiectare.

Modelul se dovedeşte deosebit de util în trei faze diferite ale proiectării: în

specificarea cerinţelor noului sistem, în activitatea de analiză a sistemului

proiectat, precum şi în activitatea de formulare a soluţiei informatice pentru sistemul proiectat şi realizare a acestuia.

Modelul contextului (în specificarea cerinţelor) Sistemul proiectat este considerat ca subsistem (cutie neagră), care funcţionează î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 funcţionale ale sistemului proiectat.

Modelul sistemului proiectat (în activitatea de analiză)

Modelul reprezintă sistemul proiectat, văzut din interior. Acesta se compune din obiecte care reprezintă o abstractizare a conceptelor manipulate de utilizator precum şi relaţiile dintre acestea. Se au în vedere: structura statică şi comportamentul dinamic al sistemului.

Modelul soluţiei informatice (în activitatea de realizare)

Modelul corespunde mijloacelor de realizare efectivă a sistemului proiectat şi evidenţiază conceptele informatice utilizate ca instrumente, limbaje sau platforme de dezvoltare. Modelul serveşte la studierea şi anticiparea unei soluţii.

Observaţie. Este de preferat să se descopere o eventuală eroare de concepţie pe un model, decât în faza de exploatare sau de testare a sistemului deja realizat.

Lucrările de specialitate menţionează următoarele patru principii ale modelării 1 :

Primul principiu: Alegerea modelelor influenţează esenţial maniera de abordare a

problemelor şi soluţionarea lor. Cu alte cuvinte, dacă este ales bine un model poate aduce clarificări nesperate alegerii celei mai bune soluţii, în timp ce o alegere greşită a modelului poate abate atenţia dezvoltatorilor de la unele probleme fundamentale. Practica arată că orientarea obiect conduce la cele mai

3

1 [BRJ] Booch Grady, Rumbaugh James, Jacobson Ivar – Le guide de l’utilizateur UML, Edition Eyrolles, 2000, pp.8-10 (trad.l.engl. The Unified Modeling Language User Guide, Addison-Wesley, 1998).

Analiza şi proiectarea orientată obiect a sistemelor informatice cu UML

bune rezultate pentru construirea unor sisteme informatice care se sprijină pe arhitecturi flexibile, chiar dacă majoritatea activităţilor 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 până la care să se coboare în realizarea diferitelor subsisteme, în funcţie de ceea ce se urmăreşte şi care sunt resursele disponibile.

Al treilea principiu: Cele mai bune modele sunt bazate pe simţul realităţii. 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.

Al patrulea principiu: Deoarece nici un model nu este suficient prin sine însuşi, este preferabil să descompunem un sistem mare într-un ansamblu de mici modele, aproape independente, care să poată fi studiate şi testate separat.

Păstrând un grad redus de interdependenţă, se micşorează considerabil riscul adoptării unui singur model. Micile modele fac deosebit de oportună atribuirea lor unor echipe de proiectare diferite, care să gândească şi să realizeze liber subsistemele de care răspund, şefului de proiect fiindu-i mult mai la îndemână coordonarea acestora.

De ce un limbaj de modelare?

Pentru a realiza un sistem, trebuie mai întâi să-l modelăm. Pentru a analiza un sistem, trebuie, de asemenea, să-l modelăm. Modelarea are nevoie de un limbaj, în primul rând ca mijloc de comunicare, pentru ca toţi factorii implicaţi, constructori şi utilizatori, să înţeleagă acelaşi lucru 2 .

4

De ce un limbaj orientat obiect?

Iată câteva din motivaţiile acestei alegeri:

1. Scopul fiecărui manager de proiect este de a putea îmbunătăţi costurile şi înlătura incertitudinile programului în timp ce caută să satisfacă cerinţele clientului. Unul din cei mai mari duşmani ai supleţei şi adaptabilităţii este automatizarea exagerată. Programele foarte complicate sunt adesea rigide, greu de modificat şi în foarte scurt timp îşi pierd eficienţa în faţa evoluţiei sistemelor obiect.

2. Pe de altă parte, atunci când pornim la construcţia unui sistem avem rareori ocazia să-i cunoaştem toate detaliile. Multe din caracteristici urmează să le descoperim pe parcurs. Interacţiunea cu utilizatorul este necunoscută. Comportamentul în timp nu poate fi decât bănuit. Factori importanţi externi şi chiar interni, cărora suntem obligaţi să le facem faţă,

2 [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).

urmează să apară după începerea proiectului. Managerul proiectului are nevoie de instrumente pentru a stăpâni cerinţele care pot apare, pentru a le rafina şi perfecţiona pe toată durata ciclului de viaţă a proiectului. Proiectarea orientată-obiect dispune de asemenea instrumente. 3. Dezvoltarea orientată obiect include şi aşa-numitele „cazuri de utilizare” – o metodă de precizare şi stăpânire a cerinţelor dinamice ale sistemului pe care o vom descrie în detaliu în cadrul acestei lucrări. „Cazurile de utilizare” cuprind un format pentru specificarea cerinţelor dinamice, care descriu în detaliu cum va reacţiona sistemul ca răspuns la interacţiunea utilizatorului. Acestea formează o punte de legătură între punctul de vedere al clientului şi cel al proiectantului, ajutând la înţelegerea în acelaşi 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 „căderii 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, construcţia şi testarea. Această metodologie primitivă era destul de rigidă şi nu permitea întoarcerea la o fază precedentă până când nu era terminată faza curentă. Întoarcerea se făcea cu pierderi materiale mari care puneau sub semnul întrebării realizarea integrală a proiectului. În general, nu exista o certitudine în construirea adevăratului sistem până 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

Analiza şi proiectarea orientată obiect a sistemelor informatice cu UML

Metoda SDLC (Systems Development Life Cycle)

Au fost realizate şi metode de management pentru planificarea, execuţia ş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 activităţi. Principalele instrumente utilizate erau diagramele de relaţii între entităţi (relation diagrams) şi diagramele de fluxuri de date

(flowcharts).

Cu toată strădania de a crea instrumente care să faciliteze realizarea practică a sistemelor informatice, SDLC păstra însă principalele inconveniente ale metodologiei „clasice”, menţionate mai sus.

Metoda SDLC iterativ

O ameliorare a acestei metode, SDLC iterativ, a apărut mai târziu, după anul 1980 şi consta în realizarea unui nucleu al sistemului în jurul căruia acesta se dezvoltă pas cu pas şi se completează pe măsura necesităţilor apărute. Nu insistăm asupra acestei soluţii care nu constituie în sine o inovaţie.

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 entităţi specifice utilizate în analiză sau componenta unei soluţii de program în faza de realizare. Corespondenţa între acestea este mai evidentă dacă limbajul utilizat este el însuşi orientat obiect (exemplu, C++ sau Java).

6

Proiectarea orientată obiect începe cu definirea actorilor umani şi a funcţiilor sistem ca obiecte care interacţionează pentru a produce un anume rezultat distinct şi important pentru proiect (artifact). Aşa se construiesc cazurile de utilizare. Apoi, cazurile de utilizare se detaliază în clase de obiecte de acelaşi fel, care conţin date caracteristice şi modurile lor de utilizare. În sfârşit, comportamentul sistemului este descris prin diagrame de secvenţă şi de colaborare între aceste clase, care se finalizează prin realizarea tuturor funcţiilor sistemului proiectat.

Caracteristicile abordării 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 trăsături care pot ajuta la înlăturarea dificultăţilor de proiectare şi întreţinere ale marilor sisteme software şi anume 4 :

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 căi de specificare,

nu numai a modului în care a fost alcătuit programul dar, de asemenea, şi cum interacţioneză obiectele între ele.

1. Descrierea

statică

şi

dinamică

a

cerinţelor.

3. Modularitatea. Sistemele sunt adesea prea complicate pentru a putea fi abordate în detaliu; ele sunt descrise, de regulă, prin blocuri funcţionale mai mici, legate între ele printr-o ierarhie. Noi utilizăm această ierarhie ca pe un prim instrument de conducere, menţinând, într-o oarecare măsură independenţa blocurilor funcţionale.

4. Încapsularea. Ascunde felul intern în care lucrează obiectele faţă de restul sistemului, permite divizarea stărilor şi definirea funcţiilor proprii fiecărui obiect. Se realizează astfel un management explicit al accesului la variabilele sistemului, acesta nefiind permis decât prin intermediul anumitor programe.

Observaţie. Clasele de obiecte utilizează atât modularitatea cât şi încapsularea. Privit din exterior, nu se vede cum lucrează un obiect; el poate fi tratat ca o „cutie neagrăcare răspunde la anumite întrebări. Acest mod de lucru facilitează înţelegerea şi permite dezvoltatorului să-şi concentreze atenţia asupra modului de utilizare a obiectelor.

5. Moştenirea. Permite mai multor tipuri de obiecte să reutilizeze proprietăţi şi să definească noi funcţionalităţi.

6. Agregarea. Creează un obiect mare din agregarea unor obiecte mici, simple, permiţând manipularea stărilor complexe.

7. Pachetele. Încapsulează obiecte în componente mai mari cu comportamente ascunse, permiţând abstractizări (ascunderea detaliilor) astfel încât programele complexe să poată fi conduse la diferite niveluri de detaliere.

7

4 Vezi [Gutu1] S.Guţu, UML – Limbaj de modelare unificat destinat managementului sistemelor complexe, în „Sisteme informatice de management”, Coordonatori L.Dumitraşcu şi M.G.Petrescu, Editura Universităţii din Ploieşti, 2004, pp.37-68.

Analiza şi proiectarea orientată obiect a sistemelor informatice cu UML

8

Principiile

de

bază

polimorfismul.

ale

abordării

obiect

sunt: încapsularea, moştenirea şi

Încapsularea – Abordarea obiect a unui sistem începe cu definirea obiectelor aparţinând domeniului studiat. În cadrul unei categorii de obiecte de acelaşi fel (clasă) se definesc, alături de tipurile de date (atribute), toate acţiunile de care obiectele aparţinând aceleiaşi clase sunt responsabile (operaţii). O clasă include toate tipurile de date şi operaţiile sale. Acesta este principiul încapsulării 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 neputând fi accesate decât prin intermediul unor metode ale clasei respective (necunoaşterea acestor metode nu permite accesul). În acest fel, datele şi metodele lor de acces formează un tot unitar de care întraga clasă este responsabilă. Moştenirea – Cel de al doilea principiu de bază este moştenirea, cu alte cuvinte transmiterea proprietăţilor unei clase (numită, în acest caz, superclasă), către o aşa zisă clasă derivată, care pe lângă caracteristicile moştenite poate avea şi alte proprietăţi. În cadrul unei clase care serveşte la căutarea lucrărilor 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 menţine aceste principii de bază s-ar putea crea în plus însă diferite criterii de selecţie: după numele autorului, cuvinte cheie ale lucrării, anul publicării, editura etc care ar mări supleţea şi rapiditatea selectării lucrărilor. Polimorfismul – În sfârşit, cel de al treilea principiu de bază al abordării obiect este polimorfismul, adică păstrarea aceleiaşi denumiri pentru operaţii asemănătoare dar cu funcţiuni diferite, identificarea făcându-se după formatul de apel (forma şi numărul parametrilor) dar şi după clasa căreia îi aparţine. Aceasta permite simplificarea înţelegerii logicii procedurilor şi acţiunilor, 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, fără vreun parametru; b) o generare mai precisă, în care să se indice numele instanţei create, eventual termenul de valabilitate etc. În acest caz, deşi metoda de generare poartă acelaşi nume, formatul de apel va fi diferit, el neavând parametri în cazul a), sau indicând 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 poziţionare pentru o serie de figuri geometrice plane (cerc, pătrat) generate, la rândul lor, în clase derivate corespunzătoare. Utilizarea aceluiaşi 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 pătrat. Î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 funcţie de clasa din care apelează metoda.

Observaţie. Marele avantaj al abordării obiect este acela că, dacă se alege ca mediu de programare tot un limbaj orientat obiect (de exemplu C++ sau Java), obiectele se păstrază şi evoluează în aceeaşi structură şi interrelaţionare, de la analiză până la realizare.

UML – standard industrial de modelare obiect

Necesitatea şi obiectivele UML

Astăzi, 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 naşterii şi dezvoltării UML. Părinţii acestui limbaj sunt consideraţi a fi Grady Booch, James Rumbaugh şi Ivar Jacobson datorită unor prime lucrări î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 alătură şi Jacobson în anul 1996. Lucrarea comună este înaintată OMG în ianuarie 1997 când apare şi prima versiune UML

1.0. adoptată la sfârşitul acestui an, după anumite completări, sub numele UML

1.1. Eforturi susţinute de standardizare din parte a OMG duc la apariţia unor

versiuni din ce în ce mai complete, aplicabile în industrie: 1.3 în anul 1999 şi UML 1.4 în septembrie 2001 5 . Astăzi se aplică pe scară largă versiunea 2.0 şi, de

9

5 A se vedea [RRRT] Rational Rose RealTime for Windows, pachet de programe comercializat de IBM, http:/www. downseek.com/download/19186.asp

Analiza şi proiectarea orientată obiect a sistemelor informatice cu UML

curând, şi-au făcut apariţia 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 UML 3.0 In- du- 2003 UML 2.0 stri- ali- zare 09/2001: vers.1.4 UML 1.4
2004
UML 3.0
In-
du-
2003
UML 2.0
stri-
ali-
zare
09/2001: vers.1.4
UML 1.4
Stan-
06/1999: vers.1.3
UML 1.3
dar-
di-
11/1997: adoptarea de către
OMG 09/1997: vers.1.1
zare
UML 1.1
OMG
01/1997: înaintarea
UML 1.0
la OMG
Partenerii UML
10/1996:
UML 0.91
06/1996:
UML 0.9
Unificarea
Metodelor
10/1995:
Metoda unificată 0.8
10/1994:
Booch’93+OMT-2
G.Booch
J.Rumbaugh
I.Jacobson
Booch-91
OMT-1
OOSE

Conform UML, un concept derivat din cerinţele utilizatorului în conformitate cu

10 cazurile lui de utilizare este proiectat mai departe în realizarea modelului şi în

6 A se vedea [VP3.2UG] Visual Paradigm for UML 3.2 – User’s Guide Copyright 1999-2004 by Visual Paradigm, http:/www.apache.org Apache Software Foundation.

programare. Invers, plecând de la program, putem descoperi cărei necesităţi îi corespunde acesta şi, în consecinţă, care este ideea care a stat la baza

proiectului (reverse engineering).

Versiunile UML 7

Din anul 1997 până în prezent, UML a cunoscut numeroase modificări, acestea fiind concretizate în versiuni mai mult sau mai puţin cunoscute publicului. Este de notat faptul că principiile UML au rămas, în general, neschimbate, versiunile UML operând în special în domeniul formalismelor utilizate (notaţii, simboluri, convenţii).

De la UML 1.0 la UML 1.1

Între versiunile UML 1.0, apărută în ianuarie 1997 şi UML 1.1 propusă în luna septembrie a aceluiaşi an, nu s-au semnalat deosebiri importante. Rolul de “îngheţare” (frozen) al asocierilor de tip compunere a fost desfiinţat. 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 apărut în anul 1998 iar UML 1.3 în anul 1999. Pentru această versiune s-au semnalat unele modificări importante.

Cazurile de utilizare

Dacă versiunea UML 1.1 recunoştea două tipuri de relaţii între cazurile de utilizare, use şi extends, ambele sub formă de stereotipuri, versiunea UML 1.3 înlocuieşte use prin include, introduce generalizarea şi defineşte extensia ca pe un stereotip de dependenţă – formă mai controlată decât relaţia de generalizare.

Diagramele de activităţi

Pentru a nota o condiţie, se poate utiliza un romb pentru a nota atât o ramificaţie cât şi o fuziune (condiţia se menţionează în paranteză).

11

7 [Fowler2] Martin Fowler - UML 2.0 CampusPress, 2004, pp.181-189 (trad.l.engl. UML Distilled – Third Edition, Addison Wesley, 2003).

Analiza şi proiectarea orientată obiect a sistemelor informatice cu UML

Bara de sincronizare poate fi sau o ramificaţie sau o joncţiune. Nu se pot adăuga condiţii arbitrare joncţiunilor. Oricărei ramificaţii trebuie să-i corespundă o joncţiune care să reunească threads create prin acea ramificaţie. Se pot imbrica

ramificaţiile şi joncţiunile şi se pot elimina din diagramă ramificaţii şi joncţiuni atunci când threads pleacă direct de la o ramificaţie la alta sau de la o joncţiune

la alta.

Joncţiunile nu sunt activate decât atunci când toate threads care intră sunt terminate. Dar puteţi avea o condiţie asupra unui thread care pleacă dintr-o ramificaţie. Dacă această condiţie este falsă, se consideră că thread este terminat pentru nevoile joncţiunii. S-a considerat că următoarele versiuni ale UML ar putea modifica total diagramele de activităţi (vezi UML 2.0).

De la UML 1.3 la UML 1.4

Cea mai importantă schimbare adusă de UML 1.4 constă în adăugarea profilurilor, ceea ce permite colectarea unui grup de extensii într-un ansamblu coerent. Documentaţia UML conţine 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 adăugat artefact-ul manifestare fizică a unei componente, s-a lucrat

asupra vizibilităţii pachetelor Java în metamodele şi asupra marcării

asincronismelor prin săgeţi în diagramele de secvenţă.

De la UML 1.4 la UML 1.5

Principala modificare a fost adăugarea unei semantici de acţiune, etapă necesară pentru a face din UML un limbaj de programare.

Principalele caracteristici ale UML 2.0

Una din schimbările cele mai evidente priveşte 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 interacţiunilor, timing şi structuri compozite.

Referitor la diagramele de clase: concepte esenţiale

12 Atributele şi asocierile unidirecţionale devin două notaţii esenţial diferite pentru a reprezenta conceptul sub-adiacent de proprietate. Multiplicităţile discontinui (exemplu [2,4]) au fost abandonate. Nu mai există proprietatea frozen. S-au adăugat noi cuvinte cheie pentru dependenţe. Cuvintele cheie <<parameter>> şi <<local>> nu se mai utilizează.

Diagramele de secvenţă

Modificarea cea mai importantă este notaţia cadrelor de interacţiune, care permite gestionarea structurilor iterative, condiţionale şi a altor structuri de control ale comportamentului. Puteţi exprima aproape în întregime algoritmii în diagramele de secvenţă. Vechile marcaje de iteraţii şi notaţiile lor au fost abandonate. Antetele de linii de viaţă nu mai sunt instanţe, 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, instanţele sunt acum specificaţii de instanţe. Clasele pot solicita interfeţe şi le pot realiza. Clasificarea multiplă utilizează ansambluri de generalizare pentru a regrupa generalizările. Componentele nu mai sunt reprezentate printr-un simbol special. Obiectele active au linii duble verticale în loc de linii groase.

Diagramele de maşini de stare

Dacă UML 1 făcea distincţia între acţiuni (momentane) şi activităţi (continue), UML 2 numeşte cele două „activităţi” şi utilizează acest termen în toate cazurile.

Diagramele de activităţi

UML 1 trata diagramele de activităţi ca pe un caz particular al diagramelor de stare. UML 2 a rupt legătura între acestea şi a suprimat regulile de corespondenţă a ramificaţiilor şi joncţiunilor pe care le instaurase UML 1. Au apărut noi notaţii, printre care acelea de semnale temporale şi de acceptare, parmetri, specificaţii de joncţiune, conectori, transformatori de fluxuri, greble de sub-diagrame, regiuni de expansiune şi terminaţii 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 joncţiune implicită. Pentru a evita confuziile, recomandăm utilizarea fuziunilor şi joncţiunilor explicite în diagramele de activităţi.

Tipuri de diagrame

13

UML este un limbaj esenţialmente grafic, ce se defineşte în jurul mai multor categorii de diagrame, fiecare dintre acestea fiind dedicată reprezentării unor

Analiza şi proiectarea orientată obiect a sistemelor informatice cu UML

concepte

particulare

ale

unui

sistem

informatic:

prima

categorie

descrie

serviciile funcţionale, a doua priveşte structura statică a sistemului iar cea de-a treia se referă la dinamica funcţionării sistemului.

Diagramele funcţionale

Diagramele funcţionale se bazează exclusiv pe cazurile de utilizare pentru specificarea cerinţelor sistemului. Paradigma de reprezentare este ilustrată în figura 1.2 şi are următoarea semnificaţie: Actorul participă la Cazul de utilizare reprezentat în diagramă. Atât actorii cât şi cazurile de utilizare trebuie să poarte denumiri unice, între cazurile de utilizare existând şi anumite relaţii de care ne vom ocupa ulterior. Cazurile de utilizare arată ce anume trebuie proiectat, fără a da vreo indicaţie cum să se facă acest lucru.

Figura 1.2 Diagrama UML. Cazuri de utilizare

acest lucru. Figura 1.2 Diagrama UML. Cazuri de utilizare Acto r Caz de utilizare Capitolul 2

Actor

Caz de utilizare

Capitolul 2 se ocupă de specificarea cerinţelor conform cazurilor de utilizare şi construirea diagramelor cazuri de utilizare.

Diagramele statice (sau structurale)

Diagramele statice, numite şi diagrame structurale, arată legăturile între diferitele elemente de structură ale modelului şi se referă la:

14

diagramele de clase;

diagramele de obiecte;

diagramele de pachete;

diagramele de structuri compozite;

diagramele de componenţă;

diagramele de desfăşurare.

Diagramele de clase

Diagramele de clase, a căror paradigmă de reprezentare este ilustrată în figura

1.3, constituie punctul central al dezvoltării obiect. În figura menţionată, clasa B – caracterizată prin atributele atribut2 şi atribut3 şi operaţiile operaţie2 şi operaţie3 – este asociată clasei A – caracterizată prin atribut1 şi operaţie1 printr-o relaţie de agregare. Cu alte cuvinte, un număr neprecizat de instanţe ale

clasei B (notat cu 0

de altă parte, clasa A este legată printr-o relaţie de generalizare /particularizare de sub-clasa A1 care îi moşteneşte proprietăţile (atribut1 şi operaţie1) având în

plus operaţie4. Pentru analiză, diagrama de clase este utilă deoarece descrie structura entităţilor 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.

*)

intră în compunerea unei instanţe aparţinând clasei A. Pe

Figura 1.3 Diagrama de clase UML

Clasa A atribut1 operaţie1()
Clasa A
atribut1
operaţie1()
Sub-clasa A1 operaţie4()
Sub-clasa A1
operaţie4()
 

Clasa B

1

0

*

atribut2

 

atribut3

operaţie2()

operaţie3()

Pe parcursul acestei lucrări, clasele au fost abordate de la simplu la complex.

Astfel, capitolul 3 se ocupă cu construirea claselor conceptuale şi a

relaţiilor dintre aceste clase. Capitolul 6 se ocupă de clasele rezultate din analiză şi arată cum se construieşte diagrama acestor clase (DCP – Diagrama Claselor

Participante la analiză).

În sfârşit, capitolul 9 se ocupă de proiectarea specificaţiilor de interfaţă

15

Analiza şi proiectarea orientată obiect a sistemelor informatice cu UML

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ă instanţe ale claselor (nu clase), de aceea se mai numesc şi

diagrame de instanţe.

Un exemplu al acestui tip de diagramă este prezentat în figura 1.4.

Figura 1.4 Diagrama de obiecte UML

centru : Întreprindere

localitate = „Bucureşti”

părinte copil copil filiala1 : Întreprindere filiala2: Întreprindere localitate = „Braşov” localitate =
părinte
copil
copil
filiala1 : Întreprindere
filiala2: Întreprindere
localitate = „Braşov”
localitate = „Constanţa”
părinte
copil

Ionescu: Angajat

localitate = „Braşov”

copil

Georgescu : Angajat

localitate = „Braşov”

16

Diagrama reprezintă o ierarhie a unor obiecte aparţinând unor clase. Numele clasei (obligatoriu) este menţionat după semnul „:” (obligatoriu). Numele

obiectului (opţional) este menţionat înaintea semnului „:”. Din diagramă se observă că:

1. Filialele sunt tot întreprinderi, prin urmare moştenesc proprietăţile acestei

clase, singura diferenţă fiind localitatea în care funcţionează;

2. Angajaţii întreprinderii moştenesc şi ei proprietăţile întreprinderii care îi

remunerează, indiferent de localitate. Angajaţii posedă caracteristici proprii care nu sunt evidenţiate în diagramă. Elementele unei diagrame de obiecte sunt specificaţii de instanţe ale claselor şi

se utilizează în cazurile complexe, acolo unde diagramele de clasă sunt greu de înţeles şi pot da naştere la interpretări 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 activităţi (vezi capitolul 8).

Diagramele de pachete

Clasele reprezintă structura de bază a unui sistem orientat obiect. Totuşi, atunci când avem de-a face cu sisteme mari, cu sute de clase, acestea devin dificil de înţeles şi necesită gruparea elementelor UML în pachete. Orice construcţie UML (cazuri de utilizare, clase, obiecte) poate fi grupată în unităţi de nivel mai înalt sub formă de pachete. Într-un model UML, fiecare clasă aparţine unui singur pachet şi poartă un nume distinct în cadrul pachetului. Pachetele pot fi, în acelaşi timp, membre ale altor pachete, ceea ce conduce la o structură ierarhizată de pachete şi clase. Un pachet poate conţine, 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 conţine, la rândul său, clasa Date.

Figura 1.5 Diagrama de pachete UML

java util Date
java
util
Date

Ceea ce este reprezentat în figura 1.5 va putea fi notat java::util::Date sau Date

(de java::util) 8 .

Diagramele de pachete sunt tratate în capitolul 2 şi capitolul 9.

17

8 Această notaţie a fost introdusă de firma Rational Rose şi nu face parte din standardul UML.

Analiza şi proiectarea orientată obiect a sistemelor informatice cu UML

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 părţi componente. În figura 1.6, de exemplu, este reprezentată clasa Telecomandă împreună cu interfeţele sale.

Figura 1.6

Diagrama de structuri composite UML (după Jim Rumbaugh)

a). reprezentarea globală b). reprezentarea compozită Telecomandă comanda TV om-maşină <<interfeţe
a). reprezentarea globală
b). reprezentarea compozită
Telecomandă
comanda TV om-maşină
<<interfeţe realizate>>
comanda TV om-maşină
comanda TV aplicaţii
<<interfeţe cerute>>
reglaj
afişare
flux de imagini
Telecomandă
:Controlor
afişare
:Generator
a).
Comanda
TV
aplicaţii
reglaj
flux de imagini
b).

Din figura 1.6 a)., nu rezultă decât că această clasă are două feluri de interfeţe:

realizate şi cerute, precum şi denumirea acestora. Din figura 1.6 b)., aflăm că această clasă se descompune, de fapt, în două părţi:

controlor şi generator iar interfeţele sunt cuplate astfel:

18

comanda TV aplicaţii, împreună cu afişarea, reglajul şi fluxul de imagini,

comanda TV om-maşină la partea numită controlor, iar

la partea numită generator.

Observaţii privind notaţiile:

1. Pentru a arăta că o parte implementează o interfaţă, am desenat un conector sub formă de cerc şi o săgeată cu linie întreruptă care soseşte în partea respectivă.

2. Pentru a arăta că o parte necesită o interfaţă, am desenat un cuplor sub formă de semicerc şi o săgeată cu linie întreruptă care pleacă din partea respectivă.

Structurile compozite sunt noi în UML 2.0 şi, datorită acestei noutăţi, este prematur să se prevadă până la ce punct se vor dovedi ele eficace în practică.

Diagramele de componenţă

Diagramele de componenţă, a căror paradigmă de reprezentare este dată în figura 1.7, constituie concepte de configurare a programelor în pachete de programe, în fişiere sursă sau în biblioteci. Aceste concepte arată cum se leagă între ele fişierele sursă, pachetele de programe şi bibliotecile, în cadrul sistemului informatic proiectat. Astfel, în figura menţionată sunt reprezentate pachetul de programe de tip <<Applet>>, care cuprinde toate programele de interfaţă om- maşină (IOM) şi care comunică cu pachetul de programe de tip <<Baza de date>> numit Clienţi. Cele două pachete de programe pot fi amplasate pe maşini diferite sau în biblioteci diferite în cadrul sistemului informatic.

Figura 1.7 Diagrama de componenţă UML

<<Applet>> IOM <<Baza de date>> Clienţi Diagramele de componenţă sunt utilizate în
<<Applet>>
IOM
<<Baza de date>>
Clienţi
Diagramele de componenţă sunt utilizate în cadrul capitolului 11.

Diagramele de desfăşurare

Diagramele de desfăşurare, a căror paradigmă de reprezentare este ilustrată în figura 1.8, corespund structurii de reţea informatică ce preia sistemul de programe şi modul în care sunt instalate componentele de reţea. Astfel, din figura 1.8 rezultă că sistemul local este constituit din serverul central, la care

sunt legate un server de înlănţuire şi un server Web.

19

Analiza şi proiectarea orientată obiect a sistemelor informatice cu UML

Figura 1.8 Diagrama de desfăşurare UML Server de înlănţuire Server central Server Web Diagramele de
Figura 1.8
Diagrama de desfăşurare UML
Server de
înlănţuire
Server
central
Server
Web
Diagramele de desfăşurare sunt utilizate în cadrul capitolului 11.

Diagramele dinamice (sau comportamentale)

Diagramele dinamice, numite şi diagrame comportamentale, arată cum

interacţionează între ele diferitele elemente ale modelului. Diagramele dinamice sunt alcătuite din:

20

diagramele de activităţi;

diagramele de stare;

diagramele de secvenţă;

diagramele de colaborare;

diagramele de vedere de ansamblu a interacţiunilor;

diagramele de timing.

Diagramele de activităţi

Diagramele de activităţi, a căror paradigmă de reprezentare este ilustrată în figura 1.9, reprezintă regulile de înlănţuire ale activităţilor în cadrul sistemului (de exemplu, navigarea într-un site Web). Activităţile sunt reprezentate prin dreptunghiuri ovalizate iar trecerea de la o activitate la alta prin săgeţi, care se întâlnesc în noduri de stare marcate prin linii verticale. Ansamblul activităţilor are

un punct de intrare şi un punct de ieşire, marcate ca în figură.

Figura 1.9 Diagrama de activităţi UML Activ.2 Activ.1 Activ.3 Diagramele de activităţi sunt tratate în
Figura 1.9
Diagrama de activităţi UML
Activ.2
Activ.1
Activ.3
Diagramele de activităţi sunt tratate în cadrul capitolelor 8 şi 12.

Diagramele de stare

Diagramele de stare, a căror paradigmă de reprezentare este ilustrată în figura 1.10, reprezintă ciclul de viaţă comun obiectelor unei aceleiaşi clase şi permit completarea cunoştinţelor claselor, atât în cadrul analizei cât şi în cazul concepţiei. Convenţia de reprezentare este inversă ca la diagramele de activităţi, cu alte cuvinte stările sunt marcate prin dreptunghiuri cu colţuri rotunjite iar drumul de la o stare la alta prin săgeţi reprezentând acţiuni specifice. Ca şi la diagramele de activităţi, există mai multe căi prin care se poate ajunge de la o stare la alta. Alegerea unei căi sau a alteia depinde de condiţiile în care se află sistemul la momentul respectiv. În diagramele din figurile 1.9 şi 1.10 nu sunt menţionate condiţiile de alegere a căilor prin care se poate ajunge de la o stare la alta.

Figura 1.10 Diagrama de stare UML Stare1 Stare2 Stare3
Figura 1.10
Diagrama de stare UML
Stare1
Stare2
Stare3

21

Analiza şi proiectarea orientată obiect a sistemelor informatice cu UML

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

Diagramele de secvenţă

Diagramele de secvenţă, a căror paradigmă de reprezentare este ilustrată în figura 1.11, servesc, în primul rând, dezvoltării de scenarii în cadrul analizei utilizării sistemului. În diagramele de secvenţă mesajele sunt reprezentate orizontal, pe o axă a timpului de sus în jos, de atâtea ori de câte ori apar.

Figura 1.11 Diagrama de secvenţă UML

:Clasa A :Clasa B :Actor m1 m2 Diagramele de secvenţă sunt tratate în capitolele 5
:Clasa A
:Clasa B
:Actor
m1
m2
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 căror paradigmă de reprezentare este ilustrată în figura 1.12, servesc aceluiaşi scop ca şi diagramele de secvenţă. În diagramele de colaborare există o singură cale, care uneşte două elemente (clase, actori), mesajele care circulă pe această cale împreună cu sensul lor fiind marcate pe marginea căii cu săgeţi. De obicei, diagramele de colaborare se construiesc pe baza diagramelor de secvenţă şi ilustrează schimburile de mesaje între obiecte în

22

9 Am menţionat că UML 2.0 numeşte acest tip de element diagramă de comunicare. Noi vom continua să păstrăm, în cadrul acestei lucrări, termenul de diagramă de colaborare, care ni se pare mai sugestiv, pentru a păstra corespondenţa cu unele lucrări mai vechi în domeniul limbajului UML.

cazul anumitor funcţionări particulare ale sistemului. Atât diagramele de secvenţă cât şi diagramele de colaborare fac parte din subclasa diagramelor de

interacţiune UML.

Figura 1.12 Diagrama de colaborare UML

1:m1 :Clasa A 2:m2 4: :Actor 3: :Clasa B Diagramele de colaborare sunt tratate în
1:m1
:Clasa A
2:m2
4:
:Actor
3:
:Clasa B
Diagramele de colaborare sunt tratate în capitolul 7, fiind apoi
reluate în cadrul capitolul 12.

Diagramele de vedere de ansamblu a interacţiunilor

Diagramele de vedere de ansamblu a interacţiunilor (ineraction overview diagrams) sunt o combinaţie între diagramele de activităţi şi diagramele de secvenţă. Ele se pot considera fie diagrame de activităţi în care activităţile sunt înlocuite prin mici diagrame de secvenţă, fie diagrame de secvenţă divizate, notaţiile având menirea să uşureze citirea acestor diagrame. În figura 1.13 este prezentat un exemplu simplu al acestui tip de diagrame. Se doreşte producerea şi formatarea unei liste recapitulative a comenzilor. Dacă clientul este extern, obţinem informaţii într-un formular XML. Dacă clientul este intern, îl obţinem dintr-o bază de date. Cele două diagrame de secvenţă ne arată cele două posibilităţi. Odată obţinute 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

Analiza şi proiectarea orientată obiect a sistemelor informatice cu UML

Figura 1.13 Diagrama de vedere de ansamblu a interacţiunilor

[date externe] [date interne] :Client :AnalizorXml :Client :BazăDeDate încarcă selecţionează analizează
[date externe]
[date interne]
:Client
:AnalizorXml
:Client
:BazăDeDate
încarcă
selecţionează
analizează
getNume
după clienţi
şi comenzi
new
getCom
new
:ComReper
new
toriuCzi
:Repertoriu
Comenzi
Listă Repertoriu Comenzi

24

Diagramele de timing

Diagramele de timing reprezintă o altă formă de diagrame de interacţiune, în care accentul este pus pe constrângerile de timp, fie pentru un obiect, fie pentru un grup de obiecte. Să luăm, pentru exemplificare, scenariul de funcţionare al unei cafetiere electrice. Aceasta se compune, în principal, din două automate: cel al pompei de evacuare al preparatului de cafea şi cel al plăcii încălzitoare. Să presupunem că între activarea pompei şi cea a plăcii încălzitoare trebuie să treacă un interval de minimum 10 secunde. Atunci când rezervorul se goleşte, pompa se opreşte, însă placa poate continua să funcţioneze încă 15 minute 10 .

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 În funcţiune Rezervor golit Oprit Pompa timp Placa În funcţiune
Figura 1.14
Diagrama de timing
În funcţiune
Rezervor golit
Oprit
Pompa
timp
Placa
În funcţiune
Oprit
încălzi-
{<15 min}
toare
{>10 s}

În figura 1.14 este reprezentată diagrama de timing pentru acest caz. Funcţionarea celor două părţi principale, pompa şi placa încălzitoare, este reprezentată pe aceeaşi diagramă a timpului. Modificările de stare sunt semnalate prin schimbări de nivel ale liniilor continue care urmăresc procesul. Liniile întrerupte verticale sunt opţionale şi ajută la precizarea momentului în care are loc evenimentul. Diagramele de timing reprezintă, de asemenea, o inovaţie adusă de UML 2.0. Ele sunt utile pentru reprezentarea restricţiilor temporale între schimbările de stare ale diferitelor obiecte.

Clasificarea diagramelor UML

În încheiere, vă prezentăm î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ă ridicăm acest tip de diagrame la un nivel superior, deoarece prezintă atât caracteristici de grupare structurală cât şi proprietăţi comportamentale. Printre caracteristicile structurale amintim:

un caz de utilizare concentrează în jurul său tot ce este semnificativ dintr- o aplicaţie ş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 proprietăţile acestora care prin interacţiune conduc la rezultatul vizat. gruparea claselor şi obiectelor implicate într-un caz de utilizare seamănă foarte mult cu aceea de pachet de nivel superior, dar semnificaţia sa este diferită, fiind legată esenţial de comportament şi scopul final al acestuia. Caracteristicile comportamentale rămân totuşi acelea esenţiale şi rezultă din faptul că la baza separării 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 Diagrama componenţă de
Figura 1.15
Diagrama UML. Cazuri de utilizare
Diagrama
de clase
Diagrama
de
Diagrama
componenţă
de
structuri
Diagrama
Diagrame
compozite
de
de
desfăşurare
structură
Diagrama
de obiecte
Diagrama
Diagrame
de pachete
Diagrama
de cazuri
Diagrama
de utilizare
de secvenţă
Diagrame
Diagrama
compor-
Diagrama
de
tamentale
de
activităţi
colaborare
Diagrama
Diagrama
de stare
vedere de
ansamblu a
Diagrame
interacţiunilor
26
de interac-
ţiune
Diagrama
de timing
Analiza şi proiectarea orientată obiect
a sistemelor informatice cu UML

2

Specificarea cerinţelor conform cazurilor de utilizare

În acest capitol:

Cazurile de utilizareţ elor conform cazurilor de utilizare În acest capitol: Diagramele cazuri de utilizare ş i elementele

Diagramele cazuri de utilizare ş i elementele lor şi elementele lor

Cazurile de utilizare

Primul pas în dezvoltarea unui proiect de sistem informatic este înţelegerea 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 specificaţia limbajului.

Fiecare caz de utilizare trebuie să aibă un nume, un număr şi o descriere.

Un caz de utilizare trebuie să respecte o anumită formă de descriere.

a. Acest caz începe atunci când

b. Sistemul răspunde prin

c. Acest caz se termină atunci când

(secvenţă de interacţiuni)

Exemplu:

Iată cum descriem cazul de utilizare: „Trasarea unei linii într-un program de desenare”.

a. Acest caz începe atunci când utilizatorul clickează pe icon-ul „linie” în bara de menu.

b. Sistemul răspunde prin schimbarea cursorului cu o cruciuliţă. Atunci când utilizatorul execută click pe desen şi trage cursorul, sistemul trasează o linie.

27

Analiza şi proiectarea orientată obiect a sistemelor informatice cu UML

c.

Acest caz se termină atunci când utilizatorul ridică degetul de pe butonul stâng al mouse-ului. Linia rămâne iar cruciuliţa dispare.

Un caz de utilizare reprezintă un ansamblu de secvenţe de acţiuni 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 cerinţele dinamice ale sistemului. Acest tip de diagrame poate fi întâlnit la două niveluri:

nivelul utilizatorului în care diagramele descriu cum interacţionează utilizatorii cu sistemul, definind astfel cerinţele sistemului; nivelul dezvoltatorului în care diagramele descriu cum interacţionează componentele sistemului, definind astfel cerinţele subsistemelor.

Fişa diagramei cazuri de utilizare este prezentată în figura 2.1. Elementele acesteia – actorii, cazurile şi relaţiile dintre ele - vor fi detaliate în cele ce urmează (figura 2.2).

28

Figura 2.1 Fişa diagramei UML cazuri de utilizare

Fişa diagramei

Cazuri de utilizare

UML

Rol

Diagrama caz de utilizare produce o primă viziune asupra structurii sistemului, un punct de plecare al proiectării, o identificare a obiectelor şi a diagramelor de secvenţă.

Elemente

Actor extern, actor intern, actor subsistem, cazuri de utilizare, relaţiile între cazurile de utilizare.

Când se

La începutul proiectării, pentru definirea modului în care sistemul corespunde cerinţelor utilizatorului. Diagramele caz de utilizare arată modul în care cazurile de utilizare se relaţionează în cadrul sistemului.

utilizează

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 mulţi actori.

Tipurile de actori sunt prezentate în detaliu în figura 2.2. Exemplele se referă la studiul de caz e-commerce şi la aplicaţiile propuse spre rezolvare (vezi TEMA).

Figura 2.2 Tipurile de actori

Element diagramă UML

Reprezentare

Actor extern Reprezintă utilizatorul sau un sistem extern care interacţionează cu sistemul în cauză. Exemple:
Actor extern
Reprezintă utilizatorul sau un sistem extern care
interacţionează cu sistemul în cauză.
Exemple:
Navigator
Căutarea lucrărilor
Navigator Gestiunea coşului
Navigator
Gestiunea coşului
Navigator Efectuarea comenzii
Navigator
Efectuarea comenzii
Navigator Gestiunea coşului Navigator Efectuarea comenzii Magazioner Între ţ inerea fi ş ierelor de magazie Ş

Magazioner

Întreţinerea fişierelor de magazie

Magazioner Între ţ inerea fi ş ierelor de magazie Ş eful sec ţ iei produc ţ

Şeful secţiei producţie

fi ş ierelor de magazie Ş eful sec ţ iei produc ţ ie Stabilirea programului de

Stabilirea programului de fabricaţie

ţ iei produc ţ ie Stabilirea programului de fabrica ţ ie Maistru Distribuirea sarcinilor pe muncitori

Maistru

Distribuirea sarcinilor pe muncitori

fabrica ţ ie Maistru Distribuirea sarcinilor pe muncitori Selectarea listei de furnizori Responsabil serviciu
fabrica ţ ie Maistru Distribuirea sarcinilor pe muncitori Selectarea listei de furnizori Responsabil serviciu

Selectarea listei de furnizori

Responsabil serviciu aprovizionare

29

Analiza şi proiectarea orientată obiect a sistemelor informatice cu UML

30

Clientul Efectuarea comenzii Efectuarea comenzii Întreţinerea catalogului Librar Întreţinerea site-ului
Clientul
Efectuarea comenzii
Efectuarea comenzii
Întreţinerea catalogului
Librar
Întreţinerea site-ului
Distribuirea
sarcinilor pe
muncitori

Denumire subsistem

Actor intern

Reprezintă funcţii ale personalului angajat
Reprezintă funcţii ale personalului angajat

Exemple:

Serviciul clienţi

Webmaster

Gestionarea magaziei de piese şi subansambluri Gestionarea magaziei de materiale

Actor subsistem

Reprezintă subsistemele automate de prelucrare a datelor privite, pentru moment, ca entităţi globale. Exemple:
Reprezintă subsistemele automate de prelucrare a datelor
privite, pentru moment, ca entităţi globale.
Exemple:
Gestiunea stocurilor
Librar
Întreţinerea
catalogului
Noutăţi
Gestiunea stocurilor Întreţinerea Magazioner fişelor de magazie Lansarea comenzilor de fabricaţie Gestiunea
Gestiunea stocurilor
Întreţinerea
Magazioner
fişelor de
magazie
Lansarea comenzilor
de fabricaţie
Gestiunea stocurilor
Gestionarea
Magazioner
fişei de magazie
Efectuarea
Elaborarea comenzii
de aprovizionat
Client
comenzii

Mai multe despre actori

31

Un actor reprezintă un rol jucat de o entitate (utilizator uman, dispozitiv material sau alt sistem) externă cazului de utilizare studiat, care interacţionează direct cu

Analiza şi proiectarea orientată obiect a sistemelor informatice cu UML

acesta din urmă. Un actor poate consulta sau modifica direct starea sistemului, emiţând sau primind mesaje purtătoare de informaţii. Actor este acela care beneficiază de utilizarea sistemului. Este de dorit să se elimine, pe cât posibil, actorii „fizici” în favoarea celor „logici”. Aceasta ne permite să depăşim tehnologiile de interfaţă care riscă să evolueze şi să identificăm „actorii logici”, susceptibili de a fi reutilizaţi. De exemplu, chiar dacă aceeaşi persoană fizică poate juca succesiv rolurile de librar şi Webmaster faţă de site-ul Web, este vorba de doi actori diferiţi, două profiluri distincte (vezi studiul de caz e-commerce).

Remarci:

În cadrul capitolului 12 al acestei lucrări se arată un mod simplu de a genera un actor folosind pachetul de programe VP-UML (vezi figura 12.8). Acelaşi mod simplu de a crea un actor avem la dispoziţie şi atunci când lucrăm cu pachetul de programe RRRT (vezi capitolul 11, paragraful 11.3 Adăugarea 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 stângă a diagramei, se vede imaginea aceluiaşi 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 cărui nume poate fi imediat redefinit.

Cazurile de utilizare

Cazurile de utilizare sunt prezentate în detaliu în figura 2.3. Exemplele se referă la studiul de caz e-commerce şi la aplicaţiile propuse spre rezolvare (vezi TEMA).

Figura 2.3 Cazurile de utilizare

Element

Reprezentare

diagramă UML

32

Caz de utilizare

Reprezentare diagram ă UML 32 Caz de utilizare Cazul A Un ansamblu de secven ţ e

Cazul A

Reprezentare diagram ă UML 32 Caz de utilizare Cazul A Un ansamblu de secven ţ e

Un ansamblu de secvenţe de acţiuni. Cazurile de utilizare indică ce anume trebuie proiectat.

Exemple:

Cazurile de utilizare indic ă ce anume trebuie proiectat. Exemple: C ă utarea lucr ă rilor

Căutarea lucrărilor

Gestionarea coşului

Efectuarea comenzii Între ţ inerea catalogului Între ţ inerea informa ţ iilor Între ţ inerea

Efectuarea comenzii

Întreţinerea catalogului

Efectuarea comenzii Între ţ inerea catalogului Între ţ inerea informa ţ iilor Între ţ inerea editoriale

Întreţinerea informaţiilor

Întreţinerea

editoriale

sistemului

ţ iilor Între ţ inerea editoriale sistemului Consultarea unei comenzi în curs Lansarea documentelor de

Consultarea unei comenzi în curs

Lansarea documentelor de fabricaţie

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ă interacţiunile “actori–sistem” şi aduce o valoare adăugată notabilă respectivului actor.

O eroare frecventă este aceea de a dori să se meargă prea în detaliu. Un caz de utilizare reprezintă secvenţe de acţiuni 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ă acţiune.

Remarci:

În cadrul capitolului 12 al acestei lucrări 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). Aceeaşi posibilitate de a crea un caz de utilizare există şi în cadrul pachetului de programe RRRT (vezi capitolul 11, paragraful 11.3 Adăugarea unui caz de utilizare şi diagrama din figura 11.9).

33

Analiza şi proiectarea orientată obiect a sistemelor informatice cu UML

Relaţii între cazurile de utilizare

Pentru a detalia diagrama cazurilor de utilizare, UML defineşte trei tipuri de relaţii standard între cazurile de utilizare:

Relaţia de incluziune.

Relaţia de extensie.

Relaţia de generalizare /specializare. Relaţiile între cazurile de utilizare sunt prezentate în detaliu în figura 2.4.

Figura 2.4 Relaţii între cazurile de utilizare

Element Reprezentare diagramă UML Incluziune A B A <<include>> B
Element
Reprezentare
diagramă UML
Incluziune
A
B
A <<include>> B

Relaţia de incluziune se foloseşte atunci când o secvenţă de ia de incluziune se folose ş te atunci când o secven ţă comportament este identic ă comportament este identică în mai multe cazuri de utilizare. Relaţia de incluziune este formalizată prin cuvântul cheie <<include>>, în care cazul de utilizare de bază încorporează explicit un altul, într-o manieră obligatorie. Săgeata de la capătul liniei întrerupte arată „ce” include iar cazul de utilizare aflat la capătul fără săgeată marchează „cine” include. Includerea se referă la întreaga procedură B înglobată în A şi executată obligatoriu odată cu A.

Exemplu:

<<include>> Analiza de risc <<include>> Expertiza Agent comercial Tarifare tranzacţie
<<include>>
Analiza de risc
<<include>> Expertiza
Agent
comercial
Tarifare tranzacţie

34

Extensie