12 UML. Sabloane de Proiectare

POOPOO- Vasile Stoicu-Tivadar Stoicu-

1 /58

Proiectarea orientat pe obiecte iUnified Modelling Language (UML)

ABLOANE DE PROIECTARE

POOPOO- Vasile Stoicu-Tivadar Stoicu-

2 /58

Avantajele analizei i proiectrii orientate pe obiecteAceste beneficii includ: eventualele schimbri n proiect sunt localizate i interaciunile cu alte module de program, improbabile motenirea i polimorfismul fac ca sistemele construite cu tehnologii orientate pe obiecte (OO) s fie mai uor de extins, realiznd astfel dezvoltare mai rapid proiectarea orientat pe obiecte eset potrivit pentru implementare paralel, distribuit sau secvenial, n egal msur obiectele corespund mai adecvat entitilor din lumea conceptual abordat de proiectant i de utilizator, putnd astfel mai uor urmri schimbrile necesare datele partajate sunt ncapsulate, reducndu-se astfel posibilitatea unor modificri neprevzute sau alte anomalii legate de actualizri ale acestora

POO - Vasile Stoicu-Tivadar Stoicu-

3 /58

Paii analizei i proiectrii orientate pe obiecteAceti pai sunt: gsirea cilor de interaciune a sistemului cu exteriorul (cazurile de utilizare) identificare a obiectelor, a atributelor i metodelor acestora stabilirea relaiilor dintre obiecte stabilirea interfeelor obiectelor i a tratrii excepiilor implementarea i testarea obiectelor asamblarea i testarea sistemului Analiza orientat pe obiecte este nu numai analiz ci conine i elemente de sintez. Astfel, abstractizarea cerinelor utilizatorului i identificarea obiectelor cheie din domeniu sunt urmate de asamblarea acestor obiecte n structuri care s suprote proiectarea efectiv n etapele ulterioare


4 /58

Ce este UML ?UML este o notaie standard internaional pentru analiza i proiectarea orientate pe obiecte. Este definit de Object Management Group (www.omg.org) UML = Unified Modelling Language UML furnizeaz elemente de notaie descrise n detaliu n Ian Graham, Object-Oriented Methods (Addison-Wesley, 2001); UML permite dezvoltare bazat pe componente. Dar UML nu nseamn numai notaii ci i un anumit principiu de gndire i modelare. Astfel, un inginer software trebuie s tie i proceduri de utilizare a notaiilor respective, n afara dezvoltrii efective de aplicaii: modelarea cerinelor afacerii (business), procesul de dezvoltare propriu-zis, gestiunea proiectelor (project management), metrici (msuri), trasabilitate, gestiunea reutilizrii software (reuse).


5 /58

UML. Introducere UML. IntroducereObiecte. Exemple. Obiecte. Exemple.


6 /58

UML . Introducere IntroducereComportament

Obiectele colaboreaz pentru a asigura funcionalitatea doritPOO- Vasile Stoicu-Tivadar OOStoicu7 /58

UML. Introducere UML. IntroducereClase Exe Clase. Exemple


8 /58

UML. Introducere UML. Introducere

Un exemplu de diagram simpl de clase (sistem autopilot cu o clas autopilor i diferii senzori i elemente de execuie pe care aceast clas i folosete)


9 /58

UML. Introducere UML. IntroducereRelaii ntre clase i obiecte Asociaii relaii care se manifest la rulare pentru a permite schimb de mesaje ntre obiecte (reprezentate prin linii simple); un mesaj este n ultim instan un apel de metod Agregare relaia stabilit atunci cnd un obiect conine logic un alt obiect (romb la captul dinspre proprietar) Compoziie - n care proprietarul este explicit responsabil pentru crearea obiectului parte (este o form tare de agregare) Generalizare (sau relaie este-parte-a(al)) linii cu sgei umplute; este inversul motenirii Dependen- (linii punctate cu sgei deschise) cnd exist o dependen ntre parteneri (ex. un software presupune utilizarea unui pachet n accepiunea din JAVA)

Multiplicitate numrul obiectelor care particip ntr-o relaie, pentru fiecare dintre cei implicai (numerele se pun la fiecare capt al liniei care simbolizeaz relaia)POO - Vasile Stoicu-Tivadar Stoicu10 /58

UML. Introducere UML. IntroducereTipul de asociere Motenire(Gen-Spec) Agregare Compoziie Asociere unidirecional Asociere bi-direcional Dependen Clas Simbol de asociere Clas

Subclas

Superclas

ntreg

Parte

ntreg Client

Parte Furnizor

A ClientPOO - Vasile Stoicu-Tivadar Stoicu-

B Furnizor11 /58

UML. Introducere UML. Introducere Diagrame de clase

Exemplu: Relaii de Clas Fereastr

Exemplu: Relaii de Clas Senzor


12 /58

UML. Introducere UML. Introducere

Diagrame UML i notaiiUML cuprinde un set bogat de notaii i semnatici i le grupeaz pe tipuri de reprezentri (diagrame) O not text - un element de diagram fr impact semantic (dreptunghi cu colul din dreapta sus ndoit) este un comentariu pentru a mbunti nelesul Constrngere restricie suplimentar adugat unui element de modelare (ntre paranteze acolad, de obicei n cadrul unei note text) Exemplu: constrngeri de timp evideniate pe diagrame de secven Note text i constrngeri


13 /58

UMLStereotipul - o clas a unei tereotipul entiti n UML care permite utilizatorilor extinderea limbajului de modelare pentru a permite acestora o mai bun exprimare conform necesitilro proiectelor (notaie cu paranteze ascuite, pe liniile ce reprezint relaia n care e implicat entitatea n cauz)

Exemple de stereotipuriPOO - Vasile Stoicu-Tivadar Stoicu14 /58

Analiza cerinelor pentru cerinelor sisteme n timp realCAZURI DE UTILIZARE (USE CASES)Un caz de utilizare este o capabilitate nominalizat a unei entiti structurale n cadrul unui model Adeseori, analiza cazurilor de utilizare se aplic sistemului ca un ntreg, dar se poate realiza i pentru alte entiti structurale, spre exemplu subsisteme sau chiar clase. Cazurile de utilizare sunt realizate prin colaborri ntre clase. Utilizare n etapele de nceput ale analizei, diagrama cazurilor de utilizare prezint capabilitile funcionale ale sistemului privit ca o cutie neagr (se vd doar intrrile i ieirile). Un actor este un obiect n afara scopului sistemului considerat dar care are interaciuni semnificative cu acesta. Un actor interacioneaz direct cu sistemul.


Exemplu: cteva cazuri de utilizare ale unui sistem de control al traficului aerian (doar un actor este un utilizator uman controlorul de zbor)15 /58

Analiza cerinelor - continuareExamplu: Sistem de Anestezie Cazuri de Utilizare

Subsistem Interfee Utilizator Cazuri de Utilizare pentru subsistem

SubsistemePOO - Vasile Stoicu-Tivadar Stoicu-

16 /58

Analiza cerinelor - continuareCerineleCerinele funcionale sunt reprezentate direct de cazurile de utilizare. Cerinele sunt codificate i sub form de restricii (constrngeri constraints). O constrngere este o regul aplicat unui set al elementelor modelului, n afara regulilor definite de UML Constrngerile sunt texte n paranteze acolad. Exemplu: {Sistemul trebuie s returneze o balan de cont n max. 30 s}POO - Vasile Stoicu-Tivadar Stoicu-

Exemplu de exprimare a Cerinelor, inclusiv prin constrngeri (v. Notele text) 17 /58

Analiza cerinelor - continuareDiagrame Diagrame de Secven Secven -prezint secvena mesajelor dintre obiecteSintaxa pentru Diagrama de secven

Liniile verticale de instan reprezint obiectele. Fiecare linie care simbolizeaz un mesaj pleac de la obiectul de origine i sfrete la obiectul destinaie i are un nume de mesaj pe linie. Acest nume poate fi nsoit n fazele ulterioare de o list de parametri (parametrii de apel ai operaiei care este apelat pentru a transmite mesajul).

Notaiile textuale identific condiiile iniiale, aciunile, activitile.POO - Vasile Stoicu-Tivadar Stoicu18 /58

Analiza cerinelor - continuareMesaje esajeMesajul Mesajul abstracie a unei uniti de comunicare ntre un obiect surs i un obiect int (cel care recepioneaz mesajul) - tipuri UML de mesaje - trimiterea unui semnal - invocarea (apelul) unei operaii - proprieti: - emitorul - lista obiectelor int - aciunea - lista parametrilor i valoarea returnat - modelul (pattern) de sosire (periodic sau aperiodic) - modelul (pattern) de sincronizare (sincron, asincron) Aciuni: SendAction asociat cu un Semnal (Signal )(o specificare a unui Stimul (Stimulus) asincron- atunci cnd un Signal este recepionat, poate genera asincron un eveniment numit SignalEvent care poate produce o tranziie de stare Exemplu: Metamodelul unei Aciuni CallAction recepionarea invocrii unei operaii (diferite tipuri de aciuni) (CallAction ) care poate produce un eveniment POO - Vasile Stoicu-Tivadar Stoicu19 /58 CallEvent n obiectul receptor

Extensii pentru Timp RealAa arat firele de execuie concurente pe o diagram de fire de execuie:


20 /58

Diagrame de stare

Analiza cerinelor - continuare

O diagram de stare conine dreptughiuri cu Exemplu: main de stare pentru cazul coluri rotunjite numite stri. de utilizare Pozitionare Telescop al unui O stare este o condiie de existen a unui sistem de comand a unui telescop clasificator (clas sau caz de utilizare) care persist o perioad semnificativ de timp i poate fi cumva distrins fa de alte condiii similare de existen. Distinctibilitatea poate fi analizat n termeni de: comportament al obiectului n timpul intrrii, ieirii sau persistenei ntr-o/dintr-o stare. evenimente acceptate n starea respectiv graful de accesibilitate al strilor subsecvente Mainile de stare sunt utile deoarece furnizeaz o descompunere a comportamentului complex n buci mai mici, fiecare fiind valabil n anumite condiii specifice. O diagram de stare este complet constructiv adic o singur diagram de stare descrie ntregul comportament al Clasificatorului al crui comportament o descrie. Un Clasificator este o metaclas n UML, care are proprietatea c are asociat o main de stare (exemple: clase, cazuri de utilizare).POO - Vasile Stoicu-Tivadar Stoicu21 /58

Analiza cerinelor - continuareIdentificarea cazurilor de utilizareExist 3 abordri primare pentru identificarea acestora: Listarea capabilitilor primare ale sistemului, apoi identificarea actorilor i scenariilor n cadrul fiecrui caz de utilizare Identicarea actorilor sistemului, a mesajelor pe care le trimit i recepioneaz (acestea alctuiesc scenariile) i apoi gruparea acestora n cazuri de utilizare se pleac de la scenarii, se identific actorii care particip la acestea apoi se agreg n cazuri de utilizare Analistul st de vorb cu clientul i i adreseaz ntrebri cheie precum: Care sunt funciile primare ale sistemului ? Care sunt funciile secundare ale sistemului ? De ce a fost construit sistemul ? Ce nlocuiete i de ce? Analistul trebuie s identifice pentru fiecare caz de utilizare: rolul actorilor i al sistemului n fiecare scenariu interaciunile (fluxurile) secvenele de evenimente i date posibilele variaiuni

Exemplu: Diagrama cazurilor de utilizare a unui Monitor ECG22 /58


Analiza cerinelor - continuareIdentificarea Cazurilor de Utilizare - continuareExemplu (continuare) Funcionalitile primare ale unui monitor ECG afiarea formelor de und eelctrocardiografice pentru medic furnizarea unor valori numerice calculate din semnale (spre exemplu frecvena btilor cardiace) furnizarea unor alarme pentru pacienii cu risc Funcionalitile secundare: furnizarea informaiilor pentru un display la distan pentru chirurgie facilitatea de actualizare a softului posibilitatea de confirgurare existena unui regim de funcionare demo De ce este construit sistemul ? (n comparaie cu altele similare) furnizeaz o mai bun detecie a aritmiilor colorarea graficelor pentru o mai bun difereniere a traseelor ECG timp de rspuns mai bun interfaarea cu reeaua spitalului i cu echipamentele de anestezie din sala de operaiiPOO - Vasile Stoicu-Tivadar Stoicu-

23 /58

Definirea structurii obiectelorConectarea Modelului de Obiecte cu Modelul Cazurilor de UtilizareEste important deoarece: Modelul cazurilor de utilizare determin modelul obiectelor (fiecare caz de utilizare va fi realizat de un set de obiecte care lucreaz mpreun n UML: colaborare) colaborare Dac suntem siguri de conectarea obiectelor la modelul cazurilor de utilizare, avem anse mai mari s realizm un sistem care corespunde cerinelor ; dar => riscul unor probleme: adugare de faciliti mai multe dect cele necesare=> testare i ntreinere mai dificile, creterea costurilor omiterea unor caracteristici deoarece cerinele nu au fost suficient de ndeaproape urmritePOO - Vasile Stoicu-Tivadar Stoicu24 /58

Definirea structurii obiectelorTable 3-1: Object Discovery Strategies Strategy Underline the noun Description Used to gain a first-cut object list, the analyst underlines each noun or noun-phrase in the problem statement and evaluates it as a potential object. Identify the sources of actions, events, and messages; includes the coordinators of actions. Identify the targets of actions, events, and messages, as well as entities that passively provide services when requested. Real-world items are entities that exist in the real world but are not necessarily electronic devices. Examples include objects such as respiratory gases, air pressures, forces, anatomical organs, chemicals, vats, and so forth. Physical devices include the sensors and actuators provided by the system, as well as the electronic devices they monitor or control. In the internal architecture, they are processors or ancillary electronic "widgets."

Dup ce modelul obiectelor a fost creat, cazurile de utilizare de la nivelul sistemului pot fi rafinare pentru a lua n considerare obiectele identificare i relaiile dintre acestea.

Identify causal objects Identify services (passive Identify realworld items

Identify physical devices

Identify key concepts

Strategii cheie Strategii pentru identificarea obiectelorCel mai bune stfel de strategii:

Key concepts may be modeled as objects. Bank accounts exist only conceptually, but are important objects in a banking domain. Frequency bins for an online autocorrelator may also be objects. Identify Transactions are finite instances of associations transactions between objects that persist for some significant period of time. Examples include bus messages and queued data. Identify Information that must persist for significant periods of persistent time may be objects or attributes. This persistence may information extend beyond the power cycling of the device. Identify visual User interface elements that display data are objects elements within the user interface domain, such as windows, buttons, scroll bars, menus, histograms, waveforms, icons, bitmaps, and fonts. Identify control Control elements are objects that provide the interface elements for the user (or some external device) to control system behavior. Apply scenarios Walk through scenarios using the identified objects. Missing objects will become apparent when required actions cannot be achieved with existing objects.


25 /58

Definirea structurii obiectelorDefinirea relaiilor dintre clase relaiilorTipuri de relaii: asocierea agregarea compoziia generalizarea dependena Asocierile sunt structurale, nsemnnd c trebuie s fie parte a claselor din care sunt instanele (de aceea analiza consider c asocierile aparin claselor). Instanele asocierilor , numite legturi, sunt definite ntre obiecte si pot s apar i s dispar n timpul execuiei ca legturi , pentru ca aceste obiecte s i realizeze rolurile n cadrul colaborrilor. Agregarea i compoziia sunt forme specializate de Agregarea asociere care implic un mai mare grad de proprietate i responsabilitate. Generalizarea Generalizarea este o relaie dintre clase (mai degrab dect dinter obiecte) deoarece definete un set de atribute, comportament i interfee pentru clasele descendente. Dependena Dependena nseamn c un element de model depinde cumva de un alt element (exemplu: o dependen la compilare, ntre pachete n accepiunea din JAVA).

Exemplu: o diagram de clase cu clasele primare controller, senzor i element de execuie, cuprinznd 4 din aceste tipuri de relaii.


26 /58

Definirea structurii obiectelor AsocierileSunt logic bidirecionale dac nu se definesc constrngeri explicite. Exemple: El are un cine. Cinele i aparine. sau Floor Request Button trimite o cerere la Elevator (Lift) Elevator primete o cerere de la Floor Request Button (ButonCerereEtaj). n practic sunt exercitate ntr-un singur sens. Exemplu: Dog.SendTail->Wag mai degrab dect Tail.SendDog->Wag (Caine.TrimiteCatreCoada->DaDinCoada mai degrab dect Coad.TrimiteLaCaine->DaDinCoada) Cel mai adesea sunt implementate ca i pointeri sau referine la obiecte. Exemplu: Class Dog { Tail* pT; public: void BeHappy(void) { pT->Wag(20); }; void BeSad(void) { pT->Wag(2); }; void BeExcited(void) { pT->Wag(50); }; void BeMelancholy(void) { pT->Wag(5); }; }; Asocierile navigabile ntr-o singur direcie sunt cunoscute sub numele de asocieri client-server clientServerele nu trebuie s tie despre clieni deoarece ar introduce asfel cuplaje patologice (nedorite, bolnave) i adugarea de noi clieni ar fi mai dificil Este necesar un singur nume de rol pentru o asociere unidirecionale (tipic, la captul dinspre server) Asocierile Peer-to-peer (adic egale n ranG, fr delimitare client-server) sunt mai puin uzuale : Peer-toFiecare obiect trebuie s tie despre cellalt n general sunt implementate ca dou relaii independente client-server POO - Vasile Stoicu-Tivadar Stoicu27 /58

Definirea structurii obiectelorAgregarea i Compoziia Agregarea CompoziiaAgregarea este un tip special de asociere care implic proprietatea logic sau fizic. gregarea Unii autori prefer termenul agregare, alii, termenul parte/ntreg agregare parte/ntreg. Poate fi fizic - dac multiplicitatea captului parte este 1 (adic ntregul acceseaz direct partea) catalog dac multiplicitatea prii este fie opional fie mai mare ca 1 Ambele tipuri de agregare suport partajarea acelorai pri ntre diveri proprietari.

Compoziia este o form tare de agregare, n care prile Compoziia (componentele) sunt n ntregime n responsabiliyayea clasei compozite. Compozitele trebuie s i creeze i distrug componentele. Componentele nu pot fi partajate nter compozite. Compoziia este reprezentat prin includere grafic a componentelor n cadrul compozitelor sau prin romb de agregare umplut. Dac se folosete includerea, multiplictatea trebuie precizat n colul din dreapta sus.


28 /58

Definirea structurii obiectelorClase asociativen sistemele distribuite, exemplul cel mai la ndemn de clas asociativ este clasa mesaj. mesaj n afar de informaia de trimis, obiectul mesaj poate s conin informaii adiionale specifice legturii i relaiei: prioritate, calea mesajului, indetificator de sesiune, numr de secven, informaie de control al fluxului, informaii despre formatul datelor i a integritii acestora (exemplu: sume de control) etc. O clas asociativ este folosit cnd inforamiile nu par s aparin nici unui obiect implicat n asociaie sau mai degrab aparine n mod egal ambelor. Exemplu: ntr-o cstorie (asociere ntre dou persoane) unde localizm apartenena urmtoarelor atribute ? data cstoriei, locul etc. n exemplul modelului sistemului distributi din figur, un subsistem conine clasa senzor i acioneaz ca un server pentru datele de la senzori. Subsistemul client afieaz datele pentru utilizator. Asocierea dintre serverul de msurare i clienli de afiare este de interes pentru acest exemplu. POO - Vasile Stoicu-Tivadar Stoicu-

29 /58

Definirea structurii obiectelorGeneralizareaClasa cea mai sus n ierarhie se numete printe, generalizare, de baz sau generalizare, superclas. Clasele derivate au toate proprietile prinilor dar pot s le extind sau s le specializeze. Atunci cnd mulimea subclaselor (claselor derivate) enumer toate posibilele subclase innd cont de caractersiticile acestora, aceast mulime de subclase -> complet complet Exemplu: Subclasele buton sunt specializate pe linii de comportament. In UML generalizarea implic: motenirea (o sublcas are toate atributele, operaiile, asocierile i dependenele superclasei sale) Subclasa poate s specializeze (subclasa poate s redefineasc polimorfic o operaie) specializeze extind proprieti motenite (subclasa poate s adauge noi atribute, operaii, asocieri .a.m.d.) xtind substitutabilitatea (o instan a unei subclase poate fi substituit totdeauna cu o instan a superclasei substitutabilitatea sale, fr a nclca semantica modelului Principiul de Substituie al lui Liskov - PSL) PSL adic putem folosi pointeri de tipul clasei de baz pentru a accesa metode ale unor obiecte d e tip derivat (dar numai pentru metode motenite) POO - Vasile Stoicu-Tivadar Stoicu30 /58

Definirea structurii obiectelorExemple de specializare i PSL: void main(void) { Animal *A; dog d; fish f; cat c; A=&d; A->speak(); A=&f; A->speak(); A=&c; A->speak(); }; class Animal { public: virtual void speak (void)=0; // virtual base class }; class dog: public Animal { public: void speak (void) { cout

12 UML. Sabloane de Proiectare

Documents

Transcript of 12 UML. Sabloane de Proiectare