CAPITOLUL III MODELARE ORIENTAT OBIECT Tehnicile orientate obiect i au originea la nceputul anilor 80.

Lucrrile de referin ce trateaz metodele de analiz i proiectare orientate obiect au aprut ncepnd cu 1988. n paralel, utilizarea programrii vizuale a determinat creterea nivelului de abstractizare, extinderea posibilitilor de exprimare, automatizarea trecerii de la proiectare la implementare, definirea unor modaliti sporite de verificare. Simbolurile grafice i automatizarea activitilor ntreprinse permit o nelegere mai bun a domeniului aplicaiei, o apropiere chiar a nespecialitilor n informatic de utilizarea tehnicii de calcul. n condiiile n care s-au dezvoltat mai multe metode pentru definirea unor modele ale sistemului real, cnd exist puncte de vedere diferite i termeni diferii pentru aceleai adevruri, se impune introducerea unor standarde la nivelul definirii modelelor i a strategiei de proiectare a sistemelor complexe. Un limbaj de modelare comun pentru construirea obiectelor permite realizarea de aplicaii indiferent de limbajul de programare. Un set bine definit de simboluri standard permite profesionitilor s comunice eficient i s produc rezultate previzibile i repetabile. Unificarea limbajului i a metodologiei care acoper integral etapele realizrii unei aplicaii prezint numeroase avantaje, dintre care se pot meniona: eliminarea conceptelor care nu s-au dovedit viabile; eliminarea unor diferene de concepte i notaii existente ntre principalele metode; realizarea unei stabiliti privind instrumentele CASE.

Exist ns i dezavantaje. n urma unificrii crete numrul de concepte utilizate, noul limbaj dobndete o complexitate prea mare, se extinde sfera de aplicabilitate uneori n detrimentul aplicaiilor specifice unui anumit domeniu.

3.1 UML limbaj standard de modelare

3.1.1 Descrierea limbajului Unified Modeling Language (UML) este succesorul unui val de metode de analiz i proiectare orientate obiect, aprute la sfritul anilor 80 i nceputul anilor 90. Este un limbaj unificat de modelare, rezultatul unui proces de introducere a standardizrii n analiza i proiectarea orientate obiect. Este punctul de pornire n dezvoltarea viitoarelor limbaje grafice. Contribuii eseniale n definirea limbajului unificat de modelare au avut Grady Booch, Jim Rumbaugh i Ivar Jacobson. Grady Booch, cercettor tiintific la Rational Software Corporation a construit numeroase exemple pentru dezvoltarea sistemului Ada. A definit o metod de analiz i proiectare a sistemelor orientate obiect Object Oriented Design (OOD). Jim Rumbaugh a condus o echip de cercetare n laboratorul General Electric, punnd bazele metodei Object Modeling Technique (OMT). Ivar Jacobson, n urma experienei dobndite n domeniul telefoniei, a introdus pentru prima dat diagramele de utilizare, n lucrarea Object-Oriented Software Engineerig - A Use Case Driven Approach. Metodele existente n acea perioad erau similare, dar conceptele de baz apreau cu mici diferene de notaii ce ddeau natere la confuzii ntre utilizatori. La OOPSLA95 Grady Booch i Jim Rumbaugh au prezentat public versiunea 0.8 a documentaiei pentru o metod standard de modelare, Unified Method (UM). Metoda consta ntr-un limbaj de modelare i un proces. Limbajul

de modelare era (n special cel grafic) notaia folosit de metod. Procesul exprima paii fcui. Studiul acestei metode i-au determinat s considere c partea de proces a metodei este nesemnificativ, c nu e nevoie i de un proces standard, dei armonizri n vocabular sunt necesare. n acelai timp, au considerat c un limbaj de modelare standard este necesar i important. i astfel, ncepnd cu 1966, cei doi mpreun cu Ivar Jacobson, au lucrat pentru un limbaj de modelare standard, Unified Modeling Language (UML). La 17 noiembrie 1997, Object Management Group (OMG) a anunat adoptarea specificaiei UML ca limbaj standard de modelare. Afirmnd c UML este experien, experiment i adoptare gradat a standardului care dezvluie adevratul potenial al sistemului i permite realizarea beneficiilor, au definit UML ca un limbaj de modelare pentru a specifica, vizualiza, construi i documenta componentele unui sistem dinamic, n care o metod este aplicat ca un proces pentru a defini i dezvolta sistemul. Mai mult, au demonstrat c UML: este limbaj folosit pentru comunicare, mijloc de a prezenta cunotine (semantic) despre sistemul studiat i de a exprima cunotinele (sintactic) privind sistemul studiat n scopul comunicrii. este limbaj de modelare ce accentuaz nelegerea sistemului prin definirea unui model al su i al contextului n care se dezvolt mbin teoria sistemele informatice i practica domeniilor de activitate concrete; specific cerinele sistemului i modul n care pot fi ele realizate. aplicat n prezentare, poate fi folosit pentru vizualizarea sistemului nainte de a fi realizat. aplicat n construirea sistemului, poate fi folosit ca ghid n realizarea unui sistem similar modelului. aplicat n documentarea sistemului poate fi folosit pentru includerea cunotinelor despre sistem n timpul ciclului de via.

Pentru a demonstra c UML nu privete doar sistemele orientate obiect, putnd fi aplicat sistemelor n general, n The Visual Modeling of Software Architecture for the Enterprise[BG99], Grady Booch a artat c modelarea este partea central a activitii care conduce la proiectarea eficient a oricrui sistem informatic. Indiferent de domeniu, pentru rezolvarea problemelor din sistemele reale se construiesc modele pentru o mai bun nelegere a sistemului, pentru vizualizarea i controlul arhitecturii sistemului. Vizualizarea, specificarea, construirea i documentarea permit ca el s fie vzut din diferite perspective. Analiza, dezvoltarea, interogrile i testele refer sistemul n diferite etape. UML ajut programatorii s nglobeze deciziile semnificative luate la nivel de sistem i proiectanii s controleze dezvoltarea iterativ a sistemului n ciclul su de via. 3.1.2 Definirea limbajului Pentru definirea limbajului sunt folosite patru documente: UML Semantics, UML Notation Guide i UML Extetions. a) UML Semantics este un model logic, cuprinznd semantica declarativ fr detaliile de implementare, este documentul principal care descrie limbajul n trei seciuni: Sintaxa abstract (Abstract syntax), n care diagramele claselor UML sunt folosite pentru a defini metamodelul UML, conceptele sale (metaclase), relaiile i restriciile. Sunt incluse i definiiile conceptelor. Metamodelul, modelul elementelor modelate, este prezentat ca un limbaj pentru specificarea modelului obiect. Scopul metamodelului UML este s furnizeze un singur, comun i definitiv sens al sintacticii i semanticii elementelor UML. Regulile de corectitudine (Well-formedness rules), n care sunt definite regulile i restriciile modelului. Object Constraint Language (OCL) este un limbaj specific care folosete logica simpl pentru specificarea proprietilor invariante ale sistemului i relaiile. Este prima contribuie IBM la UML, dezvoltat n cadrul limbajului de modelare pentru sistemele informatice din

mediile de afaceri. Furnizeaz faciliti pentru formalizarea semanticii limbajului, pentru exprimarea structurii modelului i a restriciilor. Semantica (Semantics), n care semnificaia modelului i cerinele suplimentare, non-funcionale, sunt specificate ca cerine textuale. n descrierea semanticii sunt folosite tehnici formale, definiiile sunt prezentate riguros matematic i fr ambiguiti, folosind elemente de calculul predicatelor. Totui valoarea acestor definiii nu are neles universal. Chiar dac se pot demonstra specificaiile matematice, nu exist ci de a proba aceste specificaii n contact cu cerinele reale din sistem. Modelele orientate obiect au puin rigoare. Notaia lor apeleaz mai mult la intuiie dect la definiiile formale. Pot fi informale, muli apeleaz la ele, i acest lucru conteaz. Metodele orientate obiect caut s mbunteasc rigoarea fr a pierde din utilitate. O modalitate de a face acest lucru este a defini un metamodel, o diagram a claselor care definete notaia. b) Notaia este partea grafic vzut n model, este sintaxa limbajului de modelare. Notaia din diagrama claselor definete modul n care sunt reprezentate conceptele de clas, asociere i multiplicitate. UML Notation Guide este un document utilizat practic n toate metodele de analiz i proiectare. Este structurat n conformitate cu documentele principale (diagramele) ce pot fi construite n procesul de aplicare a metodei. UML Notation Guide descrie notaiile UML i furnizeaz exemple. Face sumarul semanticii UML, definiiile fiind ns n UML Semantics. Este o reprezentare la nivelul modelului utilizatorului, care e semantic o instan a metamodelului UML. c) UML Extensions cuprinde definirea extensiilor UML care sunt posibile prin folosirea stereotipurilor (Stereotypes), valorilor etichetate (Tagged values) i restriciilor (Constraints). Sunt definite dou extensii: UML Extension for the Objectory Process for Software Engineeering i UML Extension for Business Modeling. Se apeleaz la extensii doar cnd este necesar introducerea de noi notaii i terminologii. Extensiile nu sunt universal acceptate, nelese i suportate. Chiar

fr extensii, UML este complet aplicabil pentru multe tipuri de sisteme, domenii, metode sau procese. Definete un set de concepte pentru dobndirea, partajarea i utilizarea cunotinelor mpreun cu mecanismele de extensibilitate. Ca limbaj de modelare standardizat este deschis la extensibilitate pe scar industrial, permite mbuntirea tacticii i strategiei pentru creterea valorii prin calitate i reducere de cost. Permite practicienilor creterea eficienei avnd consisten, standardizare i instrumente suportate de limbaj de modelare.

3.2 Diagrame UML

Diagramele UML sunt mijloacele de reprezentare i vizualizare a elementelor de modelare. 3.2.1 Diagrama cazurilor de utilizare Comportamentul unui sistem din punctul de vedere al utilizatorului este descric cu ajutorul cazurilor de utilizare. Ele permit utilizatorilor s-i structureze cerinele, s defineasc modul n care vor interaciona cu sistemul pentru a obine rezultatul dorit. Un caz de utilizare este iniiat ntotdeauna de un actor i exprim o funcie a sistemului, declanat ca rspuns. Funcionalitatea complet a sistemului este dat de totalitatea cazurilor de utilizare. Diagrama cazurilor de utilizare include actorii i cazurile de utilizare. Fiecare diagram conine un set complet de evenimente iniiate de unul sau mai muli actori i specific interaciunea care are loc ntre actori i sistem. Ca abstracii ale dialogului ntre actori i sistem, cazurile de utilizare descriu interaciuni poteniale fr a intra n detaliile fiecrui scenariu. Specific doar cnd se declaneaz evenimentele, ce aciuni determin i cnd se termin, fr a cuprinde detalii funcionale. Actorii sunt elementele din sistem care genereaz sau primesc evenimente. Se determin dintre utilizatorii direci ai sistemului, dintre cei care-l interogheaz sau exploateaz. Alturi de utilizatori, pot fi actori alte sisteme sau

chiar un eveniment. Determinarea actorilor permite precizarea limitelor sistemului, a relaiilor dintre sistem i mediu, a ceea ce face parte din sistemul de dezvoltat i ceea ce nu face parte din el. Exemplu: Actor participare caz de utilizare Livrare marf Furnizor Aceeai persoan poate juca rolul mai multor actori, iniiind mai multe cazuri de utilizare. Exemplu: Gestionarul unui depozit recepioneaz marfa i o nregistreaz n fia de magazie: Receptioneaz marfa Gestionar Inregistreaz marfa

Un caz de utilizare poate avea mai muli actori, fiecare cu rolul su Exemplu: La ncheierea unui contract pentru livrarea mrfurilor particip clientul i inginerul de vnzri. Client Inginer de vinzari

Incheiere contract

UML recunoate patru categorii de actori: actori principali, persoane care utilizeaz funciile principale ale sistemului; actori secundari, persoane care efectueaz sarcini administrative sau de ntretinere; echipamente externe, echipamentele care fac parte din domeniul aplicaiei i care trebuie s fie utilizate; celelalte sisteme, categorie care grupeaz sistemele cu care viitorul sistem trebuie s interacioneze. UML definete trei tipuri de relaii ntre actori i cazurile de utilizare: Relaia de comunicare: actorul particip direct la cazul de utilizare; Exemple: clientul achit, funcionarul comercial recepioneaz marfa Relaia de incluziune: o instan a cazului de utilizare surs include i comportamentul descris de un alt caz de utilizare. Acest tip de relaie se folosete pentru simplificarea diagramei cazurilor de utilizare n situaii complexe. Exemple : n diagrama cazurilor de utilizare corespunztoare aprovizionrii cu mrfuri (fig 3.1), cazul de utilizare Incheie contract - include i cazul de utilizare - Semneaza contract cazul de utilizare Livrare marfa - include i cazul de utilizare Receptioneaza marfa cazul de utilizare Intocmeste Nir- este inclus n cazul de utilizare Receptioneaza marfa cazul de utilizare ncheiere contract- definit n sistemul informatic privind aprovizionarea cu mrfuri include i cazul de utilizare

-Semnare contract- din acelai sistem informatic. Relaia de extensie: cazul de utilizare surs poate fi extins cu comportamentul unui alt caz de utilizare destinaie. Prin relaia de extensie poate fi introdus, sub forma unui caz de utilizare distinct, un nou caz de utilizare. Exemplu: n diagrama cazurilor de utilizare corespunztoare aprovizionrii cu mrfuri (fig ), cazul de utilizare Receptioneaza marfa poate fi extins cu cazul de utilizare Returneaza marfa-

Aprovizionare Incheie contract <<include>>

Semneaza contract Furnizor Livreaza marfa <<include>> Receptioneaza marfa <<extend>> <<include>> Returneaza marfqa

Gestionar

Intocmeste NIR

fig 3.1 Descrierea unui caz de utilizare const n unul sau mai multe scenarii, numite instane ale cazului de utilizare, i include urmtoarele elemente: nceputul cazului de utilizare - evenimentul care declanseaz cazul de utilizare; sfritul cazului de utilizare - evenimentul care provoac sfritul cazului de utilizare;

 interaciunea actorilor n cadrul cazului de utilizare; schimbul de informaii n timpul interaciunilor ntre sistem i actori; cronologia i originea informaiilor, momentul nregistrrii lor n interiorul sau n exteriorul sistemului; repetrile de comportament, care pot fi descrise n secvene de cod prin structuri repetitive situaiile opionale, folosind o formulare de tipul: "Actorul alege unul dintre evenimentele urmtoare, eventual de mai multe ori. Descrierile pot fi textuale. n aceast situaie trebuie s se verifice dac cerinele exprimate formal au fost alocate cazului de utilizare specificat. Fiind prezentate n limbajul utilizatorului, neconinnd un vocabular orientat obiect, pot fi aplicate oricrui sistem dinamic, dac exist sau nu intenia de construire a unui sistem orientat obiect. n Proiectarea obiectual a sistemelor informatice [ZR01], autorii propun ca descrierea cazurilor de utilizare s cuprind: . denumire sau titlu . scop . actori .punct iniial . punct final . descriere derulare . rezultat msurabil Exemplu: n cazul acordrii unui credit pentru o firm, descrierea cazului de utilizare -Analiza documentaiei depuse- este: Denumire : Analiza documentaiei depuse Scop : Calcularea coeficientului de risc Actori: Inspectorul de credite

Punct iniial: Inspectorul de credite solicit documentaia depus de firm Punct final: Obinerea valorii coeficientului de risc Descriere derulare: inspectorul de credite solicit documentaia depus de firm dac firma este un client al bncii se verific informaiile existente despre client; dac nu, baza de date este actualizat cu datele generale ale clientului din documentaie se selecteaz informaia care contribuie la calcularea coeficientului de risc n cazul unui coeficient de risc ridicat, cererea este respins se analizeaz suma cerut de firm prin comparaie cu posibilitile bncii de a acorda creditul solicitat dac rezultatul este favorabil (nivel de responsabilitate < 100.000.000) cererea de credit este admis i nregistrat Rezultat msurabil: Cererea de credit este admis i nregistrat sau respins Pentru acest caz de utilizare avem diagrama cazului de utilizare n figura 3.2 i diagrama de secvene n figura 3.3

PCredit

Analiza documentatiei depuse Inspector de credit

fig.3.3

Inspector: solicita situatie financiara

Client:

depune situatie financiara

verifica

Fig.

calculeaza

analizeaza

[conditii indeplinite]cerere admisa

[nivel responsabilitate < 100.000.000]cerere respinsa

fig 3.4 3.2.2 Diagrama claselor i diagramele obiectelor Clasa corespunde semantic entitilor din sistemul real. O clas desemneaz un grup de obiecte care au proprieti similare (atribute), un comportament comun (operaii), relatii comune cu alte obiecte i o aceeai semantic. Obiectele sunt considerate instane ale clasei, fiind construite pornind de la clase, printr-un proces de instaniere. Un obiect are o identitate ce-l distinge de celelalte obiecte i este caracterizat printr-un ansamblu de atribute i un anumit comportament. Structura sistemului, privit ca ansamblu al claselor de obiecte i al relaiilor dintre clase, este reprezentat cu ajutorul a dou tipuri de diagrame: diagrama claselor i diagrama obiectelor. Diagrama claselor prezint structura static a sistemului dintr-un punct de vedere general. Este un graf n care nodurile sunt clase iar arcele corespund relaiilor ntre clase. n strns legtur cu ea, diagrama obiectelor evideniaz

obiectele i legturile dintre ele. Diagramele obieteclor prezint cazuri particulare, faciliteaz ntelegerea structurilor de date complexe. Reprezentarea unei clase presupune specificarea atributelor ce-i definesc structura, a operaiilor ce-i definesc comportamentul i a relaiilor cu celelalte clase. n UML, o clas este reprezentat printr-un dreptunghi n care se specific numele clasei, atributele i operaiile. Nume clas Furnizori

cod Atribute nume CitesteCod Operaii ScrieNume De asemnarea obiectelor se face prin nume individuale sau prin nume generice n locul numelor individuale; numele obiectului este subliniat. 401_furnizor : Furnizori

Fiecare atribut poate lua o valoare dintr-un domeniu de definiie specificat n reprezentarea clasei. Implicit, atributele sunt ncapsulate n obiecte, interaciunile avnd loc numai prin intermediul operaiilor. Nivelul de vizibilitate al fiecrui atribut (privat, protejat i public) se precizeaz n reprezentrile grafice ale claselor cu ajutorul caracterelor -, #, respectiv +. Operaiile sunt reprezentate mpreun cu numrul, ordinea i tipul argumentelor necesare definirii aciunii lor. n cazul cnd operaia este o funcie, se specific i tipul valorii returnate. Asocierea este o conexiune semantic bidirecional ntre clase. Ea este reprezentat printr-o linie continu ntre clasele implicate, de-a lungul creia se

scrie numele asocierii. Dac sensul de transmitere a mesajelor este unic, acesta se evideniaz printr-o sgeat de la emitor la receptor. Dac ntre dou clase exist o singur asociere, numele asocierii este suficient pentru a preciza relaia. Atunci cnd ntre dou clase exist mai multe asocieri, se folosete noiunea de rol, care exprim felul n care o clas vede o alt clas n cadrul unei asocieri. Fiecare rol al unei asocieri evideniaz ordinul de multiplicitate care arat cte obiecte ale unei clase pot fi legate unui obiect al celeilalte clase. Dintre proprietile unei asocieri, multiplicitatea este cel mai des ntlnit n diagramele de structur. Este determinat de context i evideniaz numrul instanelor unei clase ce se pot asocia cu o singur instan a altei clase. Multiplicitatea restrnge numrul de obiecte ce se afl n legtur, de aceea, cnd mai multe instane ale unei clase sunt legate la o instan a clasei asociate se folosete cazul general (n). n aplicaii cea mai important distincie se face ntre multiplicitatea zero i multiplicitatea mai muli. n diagrama claselor, multiplicitatea se specific printr-o cifr urmat eventual de semnul +, printr-un interval sau printr-o succesiune de cifre. Astfel, 1 nseamn c o instan a unei clasei este legat la o singur instan a clasei asociate; 1+ nseamn c una sau mai multe instane ale unei clase sunt legate cu o instan a clasei asociate; 2-5 nseamn c dou pn la cinci instane ale unei clase sunt legate cu o instan a clasei asociate; 1,2,3 nseamn c una, dou sau trei instane ale unei clase sunt legate cu o instan a clasei asociate. Asocierile pot fi caracterizate prin atribute i pot avea propriile lor operaii. n acest caz se reprezint ca o clas, ce are acelai nume cu asocierea i se conecteaz printr-o linie ntrerupt de asociere. Exemplu:

n cazul n care ntr-o societate comercial se contracteaz produse, preul unitar i cantitatea depind de produs dar i de condiiile specificate la ncheierea contractului, sunt deci atribute ale asocierii(fig. ). contracteaz Produse Contracte

cantitate pre unitar Diagrama claselor n cazul sistemului informatic privind aprovizionarea cu mrfuri este prezentat n figura 3.5

CContract NrContract : integer DataContract : integer TermenContract : integer IncarcaContract() ConsultaContract() V aloareContract()

CFurnizor FDenumire : string FLocalitate : string AdaugaFurnizor() AfiseazaLocalitate() ModificaFurnizor()

contracteaza *

contineC 1..* M arfaContract CantContract : integer PretContractttribute : integer V alMarfaContract() corespundeC CM arfa DenumireMarfa : string UMMarfa : string ModificaDenumire()

corespunde * livreaza * CFactura NrFactura : integer DataFactura : string TvaFactura() V alFactura()

fig 3.5

contineF

corspundeF * 1..* M arfaFactura CantFactura : real Pretfactura : real

V alMarfaFactura() Agregarea i generalizarea, ca forme de asociere prezente n procesul de ierarhizare a claselor, sunt reprezentate n diagramele de structur cu simboluri specifice. Relaia de agregare este o relaie ntre clasa ntregului i clasa unei componente. Unui ntreg cu mai multe componente i corespund mai multe relaii

de agregare. Definind apartenena componentei la ntreg se poate specifica i multiplicitatea fiecrei componente fa de ntreg. Acest mod de a defini agregarea i confer statutul de form special a asocierii. Agregarea, ca relaie de tip parte-ntreg, evideniaz o asociere ntre o clas cu rol predominant (clasa agregat) i componentele sale (agregate). Este reprezentat printr-un romb plasat la captul de asociere al clasei agregat. Exemplu: n figura ntre clasa CContract i clasa MarfaContract este o relaie de agregare ntre clasa CFactura i clasa MarfaFacturata este o relaie de agregare Generalizarea, ca relaie ntre o clas i subclasele sale, este prezent ori de cte ori se semnaleaz de-a lungul unei ierarhii proprieti comune sau operaii ce evideniaz comportament comun. Este reprezentat printr-un triunghi ce puncteaz spre superclas. Exemplu: se consider clasele: Factura, cu: atribute: numr factur, data facturii, cota Tva operaii: IncarcaDate, AfiseazaData, ValoareFactura Nir, cu atribute:numr Nir, data Nir, cod gestiune operaii: IncarcaDate, AfiseazaData, AfisezGestionar Se observ c cele dou clase au atribute i metode comune. Se poate astfel construi o superclas, Documente, care s conin atributele si metodele comune, motenite de subclasele Factura i Nir. (fig. 3.6)

Du et o m e c n N ou et:i t g r cm n e D n er Da ou et:srn a D m ti g t c n I cr a ae nac D ( t ) A ezDa) fsaa a ( i t

Ftr a ua c C a v :udfnd o Ta nei e t V ae at r ( a r Fcu ) l o a

N i r C G tue udfnd o e i n : nei e d s A eG toa( fsz e i nr) i s

Pentru a defini metode ce trebuie s fie motenite de ctre subclase UML permite definirea claselor abstracte. O clas abstract este o clas care nu este instaniabil dar ale crei clase descendente pot avea instane. Clasele abstracte pot fi particularizate prin specializare i extindere n clase concrete. O clas este desemnat ca abstract prin adugarea proprietii "Abstract" pentru fiecare element generalizabil al clasei. De exemplu (fig. 3.7), ntr-o unitate economic care are angajai cu carte de munc i n regim de colaborare, formula pentru calculul venitului brut se poate specifica la nivelul clasei abstracte. Fiecare subclas definete calculul venitului prin propria sa metod. Clasa abstract definete interfaa pentru operaie fr a furniza metoda corespunzatoare. In acest caz, operaia este abstract i fiecare subclas trebuie s furnizeze propria sa metod, implementare a operaiei abstracte. Angajat Calcul_venit(): {Abstract}

Colaborator Calcul_venit()

Salariat Calcul_venit()

fig 3.7 Clasa de origine a unei proprieti este clasa care o definete la cel mai nalt nivel. Clasa de origine definete tipul atributelor, numrul i tipul parametrilor unei operaii, tipul rezultatului precum i intenia semantic. O subclas poate aduga noi proprieti la cele existente n superclasele sale, poate restrnge tipurile sau poate redefini codul. Nu poate ns lrgi tipul i nu poate modifica codul. Redefinirea unei metode nu trebuie s modifice semantica sa. Definirea claselor abstracte permite folosirea polimorfismului. Polimorfismul desemneaz proprietatea unui element de a lua mai multe forme. n informatic termenul desemneaz un concept conform cruia un nume de obiect poate desemna instane ale unor clase diferite dar provenite din aceeai arborescen. Polimorfismul operaiilor desemneaz posibilitatea de a declana operaii diferite ca rspuns la acelai mesaj. Altfel spus, o operaie este polimorf dac realizarea sa are mai multe forme. De-a lungul unei ierarhii, interaciunile ntre obiecte pot fi descrise folosind interfaa de comunicaie definit n superclasele lor i nu operaiile definite n clasele lor. Aceasta permite scrierea unui cod abstract, detaat de particularitile fiecarei subclase. De exemplu, o procedur conceput la nivelul de abstracie al clasei Document nu trebuie s cunoasc detaliile de realizare proprii fiecrui tip de document. Fiecare document este ncrcat cu date, dar procedura de ncrcare cu date este diferit de la un tip de document la cellalt. Operaia incarcare_date() este definit n clasa Document ca o operaie abstract i fiecare subclas furnizeaz propria sa implementare. Particularitile ncrcrii cu date sunt ncapsulate n fiecare clas care este adaugat n model prin derivare din clasa Document (fig 3.8).

Document ncarcare_date(){Abstracta}

Factura incarcare_date()

Chitanta_fiscala incarcare_date()

Extrasul de cont incarcare_date()

fig 3.8 Cutarea automat a codului de executat este o consecin a legrii dinamice. Pentru adugarea unui nou tip de document, este suficient s se creeze o subclas, s se realizeze operaia incarcare_date() i eventual s se recompileze. 3.2.3 Diagrama de colaborare Diagrama de colaborare prezint un grup de obiecte i interaciunile dintre ele. Obiectele i legturile dintre ele sunt reprezentate ca n diagramele obiect. Mesajele schimbate ntre obiecte sunt reprezentate de-a lungul legturilor. Ordinea de trimitere a diferitelor mesaje este indicat printr-un numr amplasat la nceputul mesajului. Numele mesajului corespunde unei operaii definite n clasa obiectului destinatar al mesajului, argumentele sale corespunznd parametrilor actuali ai operaiei. Argumentele mesajelor sunt reprezentate n diagrame fie n pseudocod fie n sintaxa limbajului de programare. De exemplu (fig.3.9), diagrama de colaborare definit pentru a evidenia aprovizionarea cu materiale i pstrarea lor n gestiune este:

Furnizor

1:se primete factura Materiale 2: depozitare (NRCD) 3: transfer(BPTR) Gestiune

fig 3.9 Pentru a evidenia declanarea interaciunilor de ctre un element extern sistemului, n diagramele de colaborare pot fi cuprini actori. Fr a se intra n detaliile obiectelor de interfa cu utilizatorul, n acest caz primul mesaj de interaciune este trimis de actor. n faza de analiz, diagramele de colaborare urmresc scenarii definite pornind de la cazurile de utilizare. mpreun cu diagramele de secvene alctuiesc aa zisele diagrame de interaciune, ce evideniaz mesajele trimise ntre obiecte. n timp ce o diagram de secvene se construiete pentru un singur scenariu n care pot fi implicate mai multe obiecte, diagramele de colaborare conin un grup restrns de obiecte, ce pot fi implicate n mai multe scenarii. Exemplu: n sistemul informatic privind vnzarea produselor, se poate defini o diagram de colaborare ntre obiectele claselor Clieni, Facturi i Documentencasare, pentru a reprezenta modul n care au fost ncasate facturile emise pentru clieni (fig.3.10 )

Ce t li ni D u i e le t :s i g e m C n trn n r i Cn a c :i t gr o tB a nee n *

Fcui at r N atua:i t gr r c r nee F Dt f c r :srn aaatua t i g S r Fc r :c a tae atua hr Vor Fc r ( a ae atua) l

* Dcnaae oI c s r I Dc m t :i t gr d ou e nee n Sm:r a u a el I Ce t :u dfnd d l n nei e i As a a le t( f ez C n ) i i As a aFcua) f ez at r ( i

fig 3.10 n faza de proiectare, diagrama de colaborare furnizeaz un punct de vedere complet al dinamicii sistemului, evideniind comportamentul claselor ca rspuns la apariia unor evenimente, noi operaii i clasele crora le aparin. n plus, se pot specifica mpreun cu mesajele condiii ce aduc detalii suplimentare pentru implementare. Colaborrile definite pentru a urmrii anumite cerine ale utilizatorilor pot conduce la apariia sau dispariia unor obiecte, la modificarea proprietilor unui obiect, la actualizarea restriciilor de integritate sau la modificarea relaiilor dintre obiecte. Este cazul n care obiecte aparinnd aceleiai clase pot participa la colaborri diferite, n funciile de scenarii diferite ale aceluiai caz de utilizare. 3.2.4 Diagrama de secvene Diagramele de secvene ilustreaz interaciunile dintre obiecte din punct de vedere temporal. Sunt ntocmite pentru scenarii ale unui caz de utilizare, arat obiectele i interaciunile dintre ele de-a lungul unui scenariu. n diagrama de secvene apar doar obiecte ale cror clase sunt reprezentate n diagrama claselor i ntre care au fost definite relaii. Mesajele corespund operaiilor prin care obiectele comunic. Reprezint apeluri ale operaiilor descrise la nivelul claselor Pentru fiecare mesaj, n clasa obiectului destinatar trebuie s existe o operaie corespunztoare, reacia obiectului la mesajul primit. Fiecare obiect este reprezentat printr-un dreptunghi n care se nscrie numele. Linia de via a obiectului se specific printr-o bar vertical.

Mesajele sunt reprezentate prin sgei orizontale de la emitor la receptor. Convenind c timpul se scurge de sus n jos, ordinea de trimitere este dat de poziia pe axa vertical. Exemplu: n sistemul informatic privind aprovizionarea cu mrfuri, succesiunea operaiilor de la formularea unei cereri de marf i pn la livrarea efectiv a mrfii poate fi prezentat n diagrama de secvene din figura 3.11

Aprovizionare: CereMarfa

Furnizor:

Factura:

Marfa:

Confirm a Trim iteFactura

LivreazaMarfa

fig 3.11 3.2.5 Diagrama de stri Diagramele schimbrilor de stare descriu comportamentul obiectelor unei clase prin stri i evenimente. Se construiesc doar pentru clasele cu comportament interesant dinamic, completnd descrierea unui caz de utilizare. Diagramele de stri modeleaz ciclul de via al unei singure clase, evideniind i eventualele evenimente trimise de ea la alt clas din sistem. Fiecare obiect este la un moment dat ntr-o stare particular. Starea este definit de valorile atributelor sale i de legturile sale. Este un rspuns al clasei la apariia unui eveniment extern.

Exemplu: starea curent a unui tip de material poate fi: n aprovizionare, depozitat n gestiune, sau n consum la secie. Este determinat de valoarea atributului document. Dac documentul este Nir, clasa Material este asociat cu clasa Gestiune prin asocierea Depozitat n. Gestiune <Depozitat n 1..* Material document

n diagrama de stare sunt descrise operaiile ce reprezint rspuns la evenimente externe clasei. Corespund unor operaii descrise n diagrama claselor, vizibile din afara clasei, (publice) Starea este descris printr-un nume care o identific i o list de aciuni/activiti ce sunt executate la apariia unui eveniment. ntr-o diagrama de stare exist o singur stare iniial i una sau mai multe stri finale, determinate de condiiile de apariie ale evenimentelor. Tranziia de stare reprezint schimbarea strii datorit unui eveniment. Evenimentul corespunde apariiei unei situaii date n domeniul problemei. El nu are durat. Trecerea dintr-o stare n alta este instantanee, sistemul fiind ntotdeauna ntr-o stare cunoscut. Tranziia de stare este reprezentat printr-o sgeat de la starea surs la starea destinaie etichetat cu: numele evenimentului care a generat tranziia condiia de apariie a evenimentului aciunea ce se execut la apariia evenimentului Exemplu: diagrama de stri pentru o factur este cea din figura 3.12:

acceptare Sosita Do: ConsultaFz : VerificaFz Inregistrata Do: IncarcaDateFz : IncarcaDateFact [sume OP<ValFact] In curs de achitare Do: CalcValFact :AfisezAchitat : SumePartiale [sume OP=ValFact] Achitat Do: ListaSume : AfiseazaData : SeteazaStare fig 3.12 3.2.6 Diagrama de activiti Diagrama de activiti descrie comportamentul sistemului introducnd elemente de implementare. Ataat unui caz de utilizare, i detaliaz aciunile i procesele corespunztoare. Ataat unei clase cu comportament dinamic semnificativ, descrie tranziia de la o stare la alta sau algoritmul de prelucrare al operaiilor. Folosete urmtoarele elemente: aciune, tranziie, decizie.

livrare

achitare parial

Aciunea corespunde unei etape n execuia unui algoritm. Fiecare operaie, privit ca o nlnuire de aciuni, poate fi detaliat n operaii elementare. Pentru simplificarea diagramelor, aciuni omogene pot fi grupate n subactiviti. Tranziia de la o aciune la alta se reprezint printr-o sgeat etichetat eventual cu: numele evenimentului care determin tranziia condiia de apariie a evenimentului Decizia indic ramificarea unei tranziii n funcie de ndeplinirea unei condiii. n faza de analiz, diagramele de activiti completeaz descrierea cazurilor de utilizare. Pentru prezentarea derulrii aciunilor sunt folosii termeni apropiai utilizatorului. Exemple: diagrama de activiti din figura 3.13 evideniaz activitile desfurate pentru aprovizionarea cu marf i nregistrarea ei n gestiune. Poate folosi pentru completarea descrierii cazurilor de utilizare din sistemul informatic privind aprovizionarea, sau poate nsoi diagrama de secvene din cadrul aceluiai sistem informatic.

se inregistreaza factura

se verifica marfa

marfa inregistrata in Nir

marfa refuzata

intocmire OP

factura stornata

fig 3.13 diagrama de activiti din figura 3.14 evideniaz activitile desfurate n analiza ofertei unui furnizor cu care se dorete ncheierea unui contract. Poate folosi pentru completarea descrierii cazului de utilizare ncheiere contract legat de actorul Furnizor.

Analiz ofert

Alegere furnizor

Incarc furnizor nou

Actualizeaz date furnizor

Intocmeste contract

fig 3.14 n faza de proiectare, diagramele de activiti apar ataate unei clase i conin elemente de implementare a operaiilor descrise n clase. Aciunile pot fi descrise n limbaj natural, n pseudocod sau ntr-un limbaj de programare (C++, Visual Basic). Echivalente schemelor logice utilizate n programarea structurat, diagramele de activiti conin structurile fundamentale de programare: liniar, repetitiv sau alternativ. n cazul unei clase cu comportament dinamic semnificativ, pentru cazul n care modificrile de stare au o determinare intern, rezultat din efectuarea sau ncheierea unor operaii, starea este descris printr-o list de aciuni/activiti, ce se execut la apariia unui eveniment. Tranziia de la o stare la alta este determinat de ncheierea acestor aciuni sau subactiviti (tranziii interne). n aceste cazuri, diagramele de activiti nsoesc diagramele de stare.

3.3 Modelul sistemului real i diagramele UML Fiecare tip de diagram red un anumit aspect al sistemului modelat: structura statica, interaciunile ntre obiecte, componentele fizice ale unei aplicaii, interaciunile dintre utilizatori i sistem. mpreun constituie un model al lumii reale, vzut din puncte de vedere diferite i n momente de timp diferite.

diagramele sistemului

prezint

structura

comportamentul

Structura sistemului este evideniat n diagrama claselor i diagrama obiectelor. Acestea conin clase i relaii dintre ele, sau obiecte i legturile dintre ele, atunci cnd comportamentul obiectelor individuale impun modificri de structur. n acest ultim caz, structura este evideniat n plus prin diagramele de colaborare. Pentru o clas, simularea comportamentului nseamn prezentarea strilor posibile i a evenimentelor care determin tranziia de la o stare la alta. Se realizeaz cu ajutorul diagramei de stri, care cuprinde i eventualele restricii aprute pe parcursul nlnuirii stare-eveniment-stare. n cele mai multe situaii, modificrile de stare sunt determinate de evenimente survenite n afara obiectului i la care acesta reacioneaz. n cazul n care modificrile au o determinare intern, rezultat din efectuarea sau ncheierea unor aciuni, pentru reprezentarea comportamentului se definesc n plus diagrame de activitate. Pentru sistem, simularea comportamentului nseamn evidenierea interaciunilor dintre clase i obiecte. Se realizeaz cu ajutorul a trei tipuri de diagrame: de colaborare, de secvene i de activiti. Aceste diagrame prezint schimbul direct de mesaje, prin definerea unor asocieri ntre clase. Pentru fiecare mesaj, n clasa destinatar trebuie s existe o operaie corespunztoare, reacia obiectului la mesajul primit. n timp ce diagrama de activiti descrie un caz de utilizare, diagramele de secvene i de colaborare sunt ntocmite pentru scenarii ale unui caz de utilizare, arat clasele i interaciunile dintre ele de-a lungul unui scenariu. Pentru clasele cu comportament dinamic semnificativ, diagrama de stri completeaz descrierea unui caz de utilizare.

diagramele urmresc cerinele utilizatorilor

funcionalitatea

sistemului

Definirea cerinelor funcionale ale sistemului sunt evideniate n cazuri de utilizare, ce corespund unor aciuni ntreprinse de o anumit entitate (actor) pentru un grup de utilizatori. Prin evidenierea cazurilor de utilizare se delimiteaz domeniul de studiu, se stabilete o legtur direct ntre utilizatori i analitii de sistem. Funcionalitatea ntregului sistem este dat de mulimea cazurilor de utilizare, grupate ntr-o diagram a cazurilor de utilizare. Diagrama cazurilor de utilizare, reprezentare a legturii ntre actori i cazurile de utilizare corespunztoare, constituie o descriere funcional a cerinelor, structurat n raport cu unul sau mai muli actori. n etapa definirii cazurilor de utilizare nu exist obiecte. Trecerea la o structur obiect se face determinnd obiectele care colaboreaz pentru a obine funcionalitatea descris de diferitele cazuri de utilizare. Pentru aceasta se urmresc diferite scenarii posibile, privite ca instane ale cazurilor de utilizare. Se obin diagrame obiect i diagrame de secvene. Pentru cazurile algoritmilor compleci se definesc diagrame stare i diagrame de activitate. Este motivul pentru care muli autori consider c exist dou importante diagrame: diagrama cazurilor de utilizare i diagrama claselor. Cerinele utilizatorilor se regsesc n diagrama cazurilor de utilizare. Funcionalitatea sistemului exprimat n aceste cerine este transformat de analitii de sistem ntr-un model alctuit din clase i relaii ntre ele. Celelalte diagrame sunt subordonate diagramei claselor i folosesc elemente i instrumente ale metodologiei orientate obiect pentru a completa modelul claselor: diagramele de activiti i de stri aduc detalii suplimentare privind comportamentul obiectelor din clase. diagramele de colaborri i de secvene detaliaz interaciunea ntre clase diagramele de activiti cuprind elemente necesare pentru implementarea claselor.

diagramele conduc la modele statice, dinamice i funcionale ale sistemului real

Diagrama cazurilor de utilizare asigur legtura ntre cerinele utilizatorilor i realizarea acestora prin intermediul abstraciilor definite i evideniate n diferite alte diagrame. Aceste alte diagrame definesc mpreun un model al sistemului real sub aspect static, dinamic i funcional. Grupate dup aspectul evideniat, diagramele pot constitui la un moment dat pentru sistem un model static, unul dinamic sau unul funcional. ntre modele exist o strns legtur: modelul dinamic arat succesiunea n care operaiile definite n clasele modelului static sunt executate. Aciunile din modelul funcional corespund operaiilor din modelul static, actorii i cazurile de utilizare arat obiectele modelului static care sunt legate prin funcii. actorii sunt obiecte explicite din modelul obiectelor, cel care le prezint structura. Fluxurile de date de la sau spre actori reprezint operaii pentru obiecte. Pentru un obiect actor, modelul dinamic arat cnd acioneaz. Modelul dinamic al acestor obiecte este necesar pentru a determina ordinea operaiilor. modelul funcional prezint nelesul operaiilor i al restriciilor din modelul obiect, nelesul aciunilor i activitilor din modelul dinamic Toate cele trei modele sunt supuse unor restricii, ce arat fie relaiile dintre dou obiecte la un acelai moment de timp, fie ntre valori ale aceluiai obiect la momente de timp diferite. Restriciile pot fi asupra obiectelor, caz n care arat dependena parial sau total a unor obiecte de altele, pot fi asupra strilor din modelul dinamic, sau pot specifica restricii asupra operaiilor din modelul funcional. Dimensiunea static vizeaz structura sistemului, componentele i relaiile dintre ele. Este evideniat prin diagrama claselor i diagrama obiectelor. Aceste diagrame sufer modificri de-a lungul ciclului de via al sistemului, conducnd n final la un model al sistemului real, complet implementabil cu ajutorul limbajelor orientate obiect (C++ , Visual Basic).

nelegerea unui sistem nu se poate ns limita doar la evidenierea componentelor i a relaiilor dintre ele. Pentru a surprinde partea dinamic, dependent de timp, se definesc noi diagrame: diagrame de colaborare, diagrame de stare i diagrame de secvene. Pentru obiectele care colaboreaz, acestea arat care sunt i cum se modific strile unui obiect, evenimentele care cauzeaz n timp tranziia de la o stare la alta. Evideniaz secvenele de operaii ce apar ca rspuns la stimuli externi, fr a lua n calcul ce face operaia i cum este ea implementat. Dimensiunea dinamic a sistemului este prezentat prin prisma evenimentelor percepute de sistem. Apariia sau dispariia unor obiecte, modificarea proprietilor unui obiect, actualizarea restriciilor de integritate sau schimbarea relaiilor dintre obiecte, sunt doar cteva din modificrilor generate n timp de apariia unor evenimente. Aspectul funcional vizeaz fluxurile de date care circul ntre diferii actori ai sistemului. Descrie ce se ntmpl n sistem i este reprezentat cu ajutorul diagramelor cazurilor de utilizare, al diagramelor de activiti i de componente. n plus evidenierea aspectului funcional presupune identificarea datelor de intrare i a datelor de ieire din sistem, definirea procedurilor de prelucrare a datelor, identificarea restriciilor i precizarea criteriilor de optimizare.

diagramele urmresc ciclul de via al sistemului pe parcursul etapelor de analiz, proiectare i implementare
Realizarea unui sistem informatic presupune parcurgerea mai multor etape. Rezultatul se regsete de fiecare dat ntr-un model. Legtura ntre modele se pstreaz, pentru c se pornete de la elementele domeniului din sistemul real i se introduc detalii necesare implementrii pe parcursul etapei de proiectare. Sunt reprezentate aceleai elemente, ns din puncte de vedere diferite.

Parcurgerea ciclului de via al sistemului nseamn revedere, detaliere, completare a modelelor existente la un momet dat. Confirm faptul c modelele orientate obiect se dezvolt n spiral. Definite pentru sisteme noi, sau pentru a permite evoluia celor existente, diagrama cazurilor de utilizare contituie pe parcursul etapelor de analiz i proiectare cadrul de referin comun. Constituie punctul iniial n stabilirea cerinelor proiectrii i formeaz baz pentru testarea i verificarea sistemului obinut. Modelele obinute n diferite etape sunt reprezentate prin diagrame de diferite tipuri, ntre care exist legturi de moment determinate de context. n faze care se succed, fiecare model aduce o perspectiv diferit asupra sistemului, adaug noi elemente imaginilor precedente, pna n final, cnd se ajunge la o viziune de ansamblu a stadiilor prin care va trece sistemul. O aceeai diagram este folosit n scop diferit pe parcursul ciclului de via: diagrama de activiti esteataat n faza de analiz unui caz de utilizare i servete n faza de implementare la descrierea detaliat a operaiilor, la definirea schemelor logice de program. Componentele se traduc n fraze SQL sau n instruciuni de program, contribuind la redefinirea structurii unor clase. diagramele obiect sunt folosite n etapa de analiz pentru abstractizarea modelului, i n faza de proiectare pentru introducerea detaliilor necesare implementrii. Definirea modelelor nu este o activitate liniar, n sensul c diagramele definite ntr-o etap pot fi modificate n alta. nlntuirea i interaciunea modelelor are loc pe tot parcursul definirii sistemului: n faza de definire a cerinelor se stabilesc cerinele funcionale ale sistemului cu ajutorul diagramelor cazurilor de utilizare rezultatele etapei de analiz se concretizeaz ntr-o diagram a claselor i n diagrame de comportament (de secvene i de activiti)

 n etapa de proiectare sunt definite noi clase, se renun la clase care nu au relevan, sunt evideniate relaii suplimentare ntre clase. Clasele definite pentru mai multe cazuri de utilizare sunt integrate ntr-o structur unic. Se definesc diagrame de stare, se adaug detalii necesare implementrii n modelul claselor.

TESTE
Personal ID_persoana nume salariu tip de angajare Salariati sporuri Colaboratori retineri