12 UML Sabloane de Proiectare

POOPOO - Vasile StoicuStoicu-Tivadar
1 /58
Proiectarea orientat pe obiecte i

Unified Modelling Language (UML)
ABLOANE DE PROIECTARE
POOPOO - Vasile StoicuStoicu-Tivadar
2 /58
Avantajele analizei i proiectrii orientate pe obiecte

Aceste 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 StoicuStoicu-Tivadar
3 /58
Paii analizei i proiectrii orientate pe obiecte

Aceti 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. UML . Intro Introduc ducere ere

Ob Obiecte iecte. . Ex Exe emple mple. .
6 /58
UML . Introduc Introducere ere

Comportament
Obiectele colaboreaz pentru a asigura funcionalitatea dorit

POOOO- Vasile StoicuStoicu-Tivadar
7 /58

Clase Clas e. Exe Exemple
8 /58
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

Relaii 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)
10 /58

Tipul 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 Client
B Furnizor
11 /58
UML. Intro UML. Introduc ducere ere Diagrame de clase
Exemplu: Relaii de Clas Fereastr
Exemplu: Relaii de Clas Senzor
12 /58
Diagrame UML i notaii

UML 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
UML
Stereotipul tereotipul - o clas a unei 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 stereotipuri
14 /58
Analiza cerinelor cerinelor pentru sisteme n timp real

CAZURI 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 - continuare

Examplu: Sistem de Anestezie Cazuri de Utilizare
Subsistem Interfee Utilizator Cazuri de Utilizare pentru subsistem
Subsisteme
16 /58

Cerinele
Cerinele 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}
Exemplu de exprimare a Cerinelor, inclusiv prin constrngeri (v. Notele text) 17 /58

Diagrame Diagram e de Se Secv cven en -prezint secvena mesajelor dintre obiecte
Sintaxa 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.

18 /58

Mesaje esaje
Mesajul abstracie a unei uniti de comunicare ntre un Mesajul 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 StoicuStoicu-Tivadar 19 /58 CallEvent n obiectul receptor
Extensii pentru Timp Real

Aa arat firele de execuie concurente pe o diagram de fire de execuie:
20 /58
Diagrame de stare
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).
21 /58

Identificarea cazurilor de utilizare
Exist 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 ECG

22 /58

Identificarea Cazurilor de Utilizare - continuare
Exemplu (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 operaii
23 /58
Definirea structurii obiectelor

Conectarea Modelului de Obiecte cu Modelul Cazurilor de Utilizare
Este 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: colabora colaborare re) 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 urmrite
24 /58

Table 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
Strategi Strategii i cheie pentru identificarea obiectelor

Cel 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 relaiilor dintre clase
Tipuri 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 Agregarea i compoziia sunt forme specializate de asociere care implic un mai mare grad de proprietate i responsabilitate. Generalizarea este o relaie dintre clase (mai degrab dect Generalizarea dinter obiecte) deoarece definete un set de atribute, comportament i interfee pentru clasele descendente. Dependena nseamn c un element de model depinde Dependen 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 Asocierile

Sunt 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 client-server Serverele 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 Peer-to to-peer (adic egale n ranG, fr delimitare client-server) sunt mai puin uzuale : Fiecare obiect trebuie s tie despre cellalt n general sunt implementate ca dou relaii independente client-server POO - Vasile StoicuStoicu-Tivadar
27 /58

Agregarea Agregarea i Compozi Compoziia
Agregarea gregarea este un tip special de asociere care implic proprietatea logic sau fizic. Unii autori prefer termenul agrega agregare re, alii, termenul 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.
Compo Compozi ziia este o form tare de agregare, n care prile (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

Clase asociative
n 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 StoicuStoicu-Tivadar
29 /58

Generalizarea
Clasa cea mai sus n ierarhie se numete printe, generalizare, generalizare, de baz sau 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 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 specialize specializeze ze (subclasa poate s redefineasc polimorfic o operaie) extind xtind proprieti motenite (subclasa poate s adauge noi atribute, operaii, asocieri .a.m.d.) substitutabilit substitutabilitatea atea (o instan a unei subclase poate fi substituit totdeauna cu o instan a superclasei sale, fr a nclca semantica modelului Principiul de Substituie al lui Liskov - 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 StoicuStoicu-Tivadar
30 /58

Exemple 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 << Arf ! << endl; } ; }; class fish: public Animal { public: void speak (void) { cout << Blub! << endl; } ; }; class cat: public Animal { public: void speak (void) { cout << Miew ! << endl; } ; }; Example pentru extensie : class dog: public Animal { public: void speak (void) { cout << Arf ! << endl; } ; void slobber(float slobberIndex); void AttackJogger(int fearLevel); };
class cat: public Animal { public: void speak (void) { cout << Miew ! << endl; } ; void ClawFurniture(long ClawLength); void SnubOwner(void); };
Clas abstract acea clas care nu poate fi instaniat direct (conine cel puin o funcie virtual pur) POO - Vasile StoicuStoicu-Tivadar
31 /58
Definirea comportamentului obiectelor

Am vzut cum putem descompune sistemele n structuri de obiecte, inclusiv relaiile dintre acestea. O alt problem important care trebuie rezolvat n cadrul analizei orientate pe obiecte este specificarea comportamentului dinamic. Acesta leag structura obiectului, cu atributele i relaiile, astfel nct obiectul s poat s fac fa responsabilitilor sale. Operaiile unui obiect implementeaz comportamentul acestuia. Tipuri de comportament: simplu (funcii matematice simple, cutaream sortarea, un indicator care afieaz numrul de clicuri etc.) de stare (dac comportamenul se schimb datorit intrrii precedente) continual
Comportament de stare (determinat de stri -state-driven, reactiv)

O stare este o condiie ontologic (de existen) care persist o perioad semnificativ de timp, poate fi distins (difereniat) de alte astfel de condiii i este disjunct (diferit) fa de acestea. O stare este dinstinctiv fa de altele n sensul n care evenimentele acceptate tranziiile survenite ca urmare a acceptrii acestor evenimente, precum i aciunile realizate sunt diferite. O tranziie este un rspuns la un eveniment care provoac o schimbare de stare. Modelarea unui obiect ca un mainc cu stri finite (MSF) ncearc s reduc complexitatea comportamental prin asumarea urmtoarelor simplificri: Sistemul poate s parcurg doar un numr finit de condiii de existen (stri) Comportamentul sistemului este definit de mesajele i evenimentele acceptate, de aciunile ntreprinse la intrarea sau prsirea strilor, de activitile realizate ct timp obiectul persist ntr-o stare, de graful de accesibilitate, de setul complet de perechi tranziie-stare int Sistemul persist n stri pentru perioade semnificative de timp Sistemul poate schimba condiiile doar ntr-un numr finit de ci (tranziii) complete bine determinate
32 /58

Comportamentul continuu
Multe obeicte prezint un comportament continual (filtre numerice, algoritmi numerici de reglare spre exemplu buclele PID etc.) de fapt este comportament cvasi-continual, ntruct este implementat ca i calcul numeric. Ieirea curent depinde de istorie (valorile precedente de intrare i ieire) ntr-un mod netezit, continuu. UML este un limbaj de modelare discret i nu furnizeaz mijloace pentru modelarea sistemelor continuale. Cu toate acestea, modelarea respectiv poate fi realizat n limbaje de programare/modelare clasice iar UML poate fi folosit pentru a modela acele entiti de program.
Definirea comportamentului de stare al obiectelor
n metodologiile orientate pe obiect, elementele capabile de comportament de stare sunt doar Clasificatorii (clasele, cazurile de utilizare) i doar obiectele execut (funcioneaz ca) maini de stare. Strile sunt reprezentate ca dreptunghiuri cu coluri Aciunile sunt prezentate ntr-o list de aciuni, separate rotunjite. Tranziiile sunt reprezentate ca sgei care ncep de la starea de pornire i se termin la de descriptorul (eticheta) tranziiei printr-un slash. starea int. Tranziiile au de obicei asociate nume de evenimente declanatoare urmate de aciuni nterprinse dac se realizeaz tranziia. POO - Vasile StoicuStoicu-Tivadar 33 /58
Temporizator re-armabil nerepetititv

Un alt exemplu: un obiect de tip tranzacie mesaj cu o schem sigur de comunicaie. Atunci cnd obiectul emitor trimite un mesaj ctre un obiect la distan utiliznd un protocol de comunicaie sigur, un obiect tranzacie este creat temporar ; acesta persist pn cnd poate fi verificat recepia sigur de ctre obiectul care recepioneaz. Dac se scurge un interval de timp predefinit fr s se primeasc o confirmare de recepie de la obiectul care recepioneaz, mesajul este retransmis. Dup ce confirmarea este recepionat, obiectul tranzacie poate fi distrus. Tranzacia trebuie limitat la un numr finit de rencercri. Rombul reprezint o pseudo pseudo-stare de ramificare (branch pseudostate ) care permite selecia uneia din cile de tranziie pe baza unor condiii (guarding conditions). Acele Guards sunt reprezentate ntre paranteze patrate. Diagrama de stare a Tranzaciei Mesaj Dac apare un eveniment care duce la evaluarea condiiei Guard pe TRUE, atunci acea cale de tranziie este luat. POO - Vasile StoicuStoicu-Tivadar 34 /58
Definirea comportamentului obiectelor Exemplu

Stimulator cardiac
Enunul problemei: problemei
Problem Statement: A Cardiac Pacemaker A cardiac pacemaker is an implanted device that assists cardiac function when underlying pathologies make the intrinsic heart rate too low or absent. Pacemakers operate in different behavioral modes, indicated by a three-letter acronym. The first letter is either A, V, or D depending on whether the atrium, the ventricle, or both (dual), are being paced. The second letter is also A, V, or D, depending on which heart chamber is being monitored for intrinsic activity. The last letter is J, T, or D, indicating inhibited, triggered, or dual pacing modes. In an inhibited mode, a sensed heart event (that is, a detected cardiac contraction) will inhibit the delivery of a pace from the pacemaker. In triggered mode, a sensed heart event will immediately trigger a pace from the pacemaker. For example, WI mode means that the ventricle is paced (the first V) if a ventricular sense (the second V) does not occur. If a ventricular sense does occur, then the pace is inhibited (the I). Dual modes are more complex and will not be discussed here. Most of the time, a pacing pacemaker waits for a sense event. When it decides to pace, the pacemaker conducts an electric current of a programmable voltage (called the pulse amplitude) for a programmable period of time (called the pulse widtli). Following a pace, the pacemaker is put into a refractory state for a set period of time, during which all cardiac activity is ignored. Following the refractory period, the pacemaker resumes monitoring for the next cardiac event. The rate of pacing is determined by the programmable pacing rate. The period of time trie pacemaker will wait in the waiting state is computed based on the pacing rate and the pulse width. The refractory period is fixed. This particular pacemaker operates in WI, AAI, WT, AAT, and AVI pacing modes, as programmed by the physician. Pacemaker parameters are programmed via a telemetric interface to an external programmer. Telemetry is sent by pulsing an electromagnetic coil a certain number of times to indicate a "CT bit and a different number of times to indicate a "I" bit. To avoid inadvertent programming by electrical noise, a reed switch must be closed with a magnet before programming is enabled. The commands constructed from the bits must be checked prior to acting on them.
35 /58

Exemplu Stimulator Cardiac continuare continu are 1
Acest enun de problem poate fi transpus ntr-un model simplu de clase:
36 /58

Exemplu Stimulator Cardiac - continuare continuare 2
Comportamentul (diagrame de stare): Comutator Reed (acionat prin apropierea unui magnet) Driverul bobinei de recepie a comenzilor (comenzile sunt transmise prin inducie)
37 /58

Exemplu de Stimulator Cardiac - continu continuare are 3
Comportamentul Comportamentul: Modelul de stare al unitii de comunicaii Model de stare al compartimentelor inimii
38 /58

Exemplu de Stimulator Cardiac - continu continuare are 4
Comportamenul: Model de stare atrial Model de stare ventricular
Cnd Modelul Atrial recepioneaz un semnal de la Modelul ventricular n starea Waiting (ateptare), emitorul de fapt determin propagarea la Modelul Atrial a unui eveniment APace (Stimulare). Dup ce Modelul Atrial realizeaz stimularea (adic trimiterea unui semnal electric la un electrod din inim), trimite un eveniment APaceDone napoi la Modelul Ventricular. Prin trimiterea acestor evenimente n ambele sensuri ntre cele dou obiecte care colaboreaz, mainile lor de stare rmn sincronizate. POO - Vasile StoicuStoicu-Tivadar 39 /58

Diagram iagrame e de Se Secv cven en
Sunt cea mai uzual cale de reprezentare a scenariilor. Se folosesc linii verticale pentru a reprezenta obiectele care particip la scenariu i sgei orizontale pentru a reprezenta mesajele trimise ntre obiecte. Aceste reprezentri trebuie s fie strns corelate cu modelele corespunztoare de stare, iar acest lucru poate fi subliniat prin adugarea unor markeri de stare pe liniile verticale de instan, ca n exemplul de mai jos:
Notaia este o modalitate standard de a exprima temporizrile ntre mesaje sau valorile trimise (vezi figura). POO - Vasile StoicuStoicu-Tivadar
40 /58

Definirea opera operaiilor
Toate operaiile claselor manipuleaz mesaje sau ajut la aceasta. n UML, o operaie este specificarea unui comportament. Aceasta este distinct fa de metod. Metoda este realizarea unei operaii, iar operaia este cuanta fundamental de comportament al obiectului. Comportamentul general al unui obiect este descompus ntr-un set de operaii, unele din acestea avnd interfee ale clasei (adic sunt funcii publice), altele sunt interne sau ascunse (private). n cea mai simpl situaie, exist o coresponden 1-1 ntre comportamentul clasei i operaiile acesteia, dar nu neaprat. Operaiile au un protocol (set de reguli) de utilizare corect, care const n: invariani precondiionali condiii pe care mediul trebuie s le satisfac nainte de invocarea (apelul) operaiei o semntur coninnd o list ordonat de parametri formali, tipurile acestora i tipul returnat de operaie Invariani postcondiionali condiii care sunt ndeplinite garantat dac se deruleaz operaia reguli pentru interaciuni sigure ntre fire de execuie, incluznd comportamente de sincronizare n limbajele n care cerinele asupra tipurilor sunt severe, compilatorul nsui verific numrul i tipul parametrilor. Dar anumite limbaje au verificri de tip mai severe dect altele. Exemplu: n C++, indecii de matrice nu sunt verificai (dar n FORTRAN sunt verificai), dar putem suprancrca oepratorul de indexare pentru a realiza aceast verificare. n schimb, parametrii formali descrii n prototipurile de funcii sunt comparai cu parametrii actuali la apelare i neconcordanele sunt semnalate, ceea ce nu se ntmpl n C.
41 /58

Tipuri de operaii
Operaiile sunt manifestrile comportamentelor. Acestea pot fi: 1. Constructor creaz obiecte de o anumit clas. Cteodat construcia unui obiect se realizeaz n doi pai: inial, constructorul construiete infrastructura obiectului, apoi un anumit apel completeaz procesul (atunci cnd nu toate informaiile sunt disponibile la creare, pentru a putea realiza iniializarea complet a obiectului). 2. Destructor distruge obiecte de o anumit clas 3. Modificator Modificator (Modifier) schimb valori n cadrul unui obiect. 4. Selector citete valori sau solicit servicii de la un obiect fr ca acesta s fie modificat 5. Iterator furnizeaz acces ordonat la componentele unui obiect. Este uzual ca obiectele s acceseze colecii de alte obiecte numite colecii sau containere. (vezi capitolul despre Tipare)
Exemplu: o clas colecie simpl (un arbore binar): class Bunch_O_Objects { node* p; node current_node; public: void insert(node n); node* go_left(void); node* go_right(void); };
Dar o mai bun abordare ar fi furnizarea unei semantici fundamentale - conceptul de urmator (next) sau precedent (previous) : class Bunch_O_Objects { node* p; node current_node; public: void insert(node n); node* next(void); node* previous(void); };
42 /58

Poate unii clieni ar dori s caute sau mai mult, s reporneasc o cutare : Dac doi utilizatori doresc s parcurg lista cu next() n acelai timp, niciunul nu va putea citi toat lista deoarece unele elemente se duc la primul utilizator, altele la cellalt. O soluie este crearea unor obiectede tip iterator separate i fiecare iterator s aib propriul pointer de nod curent: class Bunch_O_Objects { node* p; public: void insert(node n); node* next(node* n); node* previous(node* p); friend class BOO_Iterator; }; class BOO_Iterator { node* current_node; Bunch_O_Objects& BOO; BOO_Iterator(Bunch_O_Objects& B) : BOO(B) {current_node=BOO . P; }; node* next(void); node* previous(void); node* first(); node* last(); node* find(node &n); }; POO - Vasile StoicuStoicu-Tivadar
43 /58
class Bunch_O_Objects { node* p; node current_node; public: void insert(node n); node* next(void); node* previous(void); node* first(); node* last(); node* find(node &n); };

Strategii pentru definirea operaiilor
Exist reguli euristice (rezultate din experien) care ne ajut la identificarea operaiilor: furnizarea unui set ortogonal de operaii (ct mai diferite, disjuncte) primitive (elementare, la ultimul nivel de simplitate) de interfa ascunderea structurii interne a clasei prin operaii de interfa care expun doar caracteristicile semantice eseniale ale clasei furnizarea unui set de operaii ne-primitive pentru a impune utilizarea unor reguli de protocol i surprinderea celor mai utilizate combinaii de operaii o clas printe comun ar trebui s furnizeze operaii comune utilizate de clasele nrudite fiecare responsabilitate a unei clase sau a unui obiect trebuie s corespund unei combinaii de operaii, atribute sau asociaii toate mesajele direcionate spre obiect trebuie s fie acceptate i traduse n aciuni definite (evenimente tratate de modelul de stare al clasei i mesajele prezentate n scenarii trebuie s aib operaii care s le accepte, cu operaii de tip get sau set -citire sau scriere valoare-care s asigure accesul la atribute oridecteori este necesar) aciunile i activitile identificate pe diagramele de stare trebuie s se traduc n operaii definite n clasele care furnizeaz aceste aciuni Operaia acquire() determin operaiile trebuie s testeze invarianii precondiionali class sensor respectarea unui protocol de aducere { la zero a senzorului nainte de citirea Exemplu: void doZero(); valorii. Nu doar asigur precondiia Un senzor trebuie s fie adus nti la zero int get(); pentru operaia get() prin ndeplinirea nainte de a fi folosit; clasa senzor poate public: necesitii de aducere la zero, dar de eventual n mod simplist s furnizeze int acquire(void) { asemenea simplific utillizarea clasei. operaiile primitive doZero() i get() sau doZero(); Deoarece doZero() i get() sunt poate s furnizeze o operaie acquire() care return get(); totdeauna apelate n aceast le combin: }; succesiunie, combinarea lor ntr-o }; operaie non-primitiv de utilitate curent este de dorit. POOPOO - Vasile StoicuStoicu-Tivadar 44 /58
Instrumente CASE
Exist cteva instrumente comerciale de tip CASE (Computer Aided Software Engineering instrumente software utile n mai multe etape din ciclul de via al programelor, nu numai la codificare/testare, ca i mediile utilizate la laboratorul de PC sau POO) care ofer suport pentru utilizarea UML . Multe dintre acestea sutn editoare care analizeaz corectitudinea sintactic a modelelor UML i unele chiar genereaz cod (de fapt un schelt al viitoarei aplicaii) de folos ulterior la codificare. Cea mai cunoscut astfel de aplicaie este Rose din pachetul Rational (IBM). http://www-01.ibm.com/software/awdtools/developer/rose/enterprise/index.html Este conceput s se integreze n suita Rational care ofer suport pentru toate etapele de dezvoltare software, ndeosebi dac se urmeaz metodologia RUP- Rational Unified Process (IBM). Permite crearea cazurilor de utilizare, a diagramelor de clase care le realizeaz, a tuturor celorlalte diagrame UML Marele avantaj al mediului este c se integrez n suita Rational i astfel activitile de dezvoltare software sunt integrate unitar inclusiv la nivelul gestiunii configuraiilor, testare etc. Aplicaia este capabil s genereze cod n C++, JAVA sau datorit unor extensii recente, chiar n .NET (implementruile metodelor nu sunt generate) Exist i aplicaii unele chiar gratuite care ns nu sunt de complexitatea acestui instrument. Exemplu: StarUML http://staruml.sourceforge.net/en/ POO - Vasile StoicuStoicu-Tivadar
45 /58
ABLOANE DE PROIECTARE
(Design Patterns)
46 /58
abloane de proiectare
Un ablon (pattern) o regul care exprim o relaie dintre un context, o problem i o soluie (Cristopher Alexander, 1979) Permite utilizarea soluiei de multe ori n contexte diferite Abstractizeaz i identific aspectele cheie ale unei structuri comune de proiectare pe care o face util pentru crearea unui design OO, reutilizabil. Identific clasele i instanele participante, rolurile i colaborrile lor i distribuia responsabilitilor iniial folosit n arhitectur ulterior, n proiectarea software (OO software design)
47 /58
Sabloane de proiectare - cont.

Const n: o problem comun o abordare general pentru o soluie consecinele pentru a realiza un ablon
Ex Exe emplu mplu:

Consequences: The smart pointer makes the design more robust in the presence of thrown exceptions, but it increases the code complexity somewhat and requires an additional level of indirection for each pointer reference. Although this can be made syntactically invisible to the user, it involves a small run-time overhead. Enforcement of the smart pointer policy cannot be automated, but must be ensured by consensus and review. Further, if smart and raw pointers are both applied against the same object, reference counting should be disabled.
Problem: when exception handling is used, raw pointers can lead to memory leaks when exceptions are thrown. The use of temporary pointers within normal C++ functions or class member functions may not be properly cleaned up if an exception is thrown, because the inline delete operator may be bypassed. This does not apply to objects, because when objects go out of scope, their destructors are called. Raw pointers do not have destructors.
Solution: rather than use a raw pointer, a smart pointer object can be used when a temporary pointer is needed. The smart pointer is responsible for identifying if it must deallocate memory when the pointer is destroyed. This require an interrral mechanism, such as reference counting, to determine whether other smart pointers are referring to the same object in memory.
48 /58
ABORDRI GENERICE
Idiomuri - convenii general acceptate de utilizare a unui anumit limbaj de programare. abloane de proiectare (DP) structuri n cadrul crora obiectele colaboreaz n vederea obinerii unui anumit comportament care s satisfac o anumit cerin a problemei. Cadrele (frameworks)reprezint colecii de clase care ofer un set de servicii pentru un domeniu particular. Exporta un numar de clase si mecanisme pe care utilizatorii le pot adapta.
49 /58
Exemple de abloane
50 /58
ablonul Interface
De ce interfa ? O implementare comun poate fi potrivit pentru o varietate de utilizri. Dac o clas poate furniza diverse interfee, o singur implementare poate satisface multe necesiti. Exemple: arbori, cozi sau stive pot de fapt s fie implementate ca liste nlnuite. Prin separarea de utilizator prin intermediul unei interfee, devine mai uoar schimbarea unei implementri sau adugharea unei noi interfee diferite. Exemplu: devine mai uoar adugarea unui nou container - un vector extensibil prin crearea unei interfee care asigur clienilor serviciile cerute de acetia dar folosesc operaiile promitive ale containerelor existente Interfeele pot fi construite astfel ca s asigure diverse nivele de acces. Este un ablon foarte simplu - UML funizeaz stereotipul <<interface>> Client Object are nevoie de un container tip stiv deci de un obiect myStack . Acesta nu gestioneaz direct colecia dar furnizeaz interfaa potrivit pentru Client (precum metodele Push i Pop) dar implemenetaz aceast interfa prrin utilizarea operaiilor furnizate de clasa de list nlnuit (insertAtEnd, getLast, deleteLast).
51 /58 ablonul e reprezentat ca un oval punctat din care sgei punctate arat ctre clasele din cadrul ablonului
ablonul Smart Pointer

Binecunoscute probleme sunt legate de utilizarea acestora n C++ : pot fi utilizai din greeal nainte de a fi iniializai pot fi utilizai (tot din greeal) dup ce memoria ctre care arat a fost eliberat memoria poate (eventual) s nu fie eliberat dup ce nu mai e necesar aritmetica pointerilor poate duce la erori de utilizare, de asemenea
Smart Pointer este un ablon uzual care elimin aceste surse de erori: Dac pointerii obinuii nu au constructor, smart pointers vor folosi constructori pentru a iniializa cu NULL sau a fora precondiii pentru ca pointerii s indice spre obiecte valide Dac pointerii obinuii nu au destructor, smart pointers determin dac memoria trebuie eliberat cnd nu mai e necesar Dac pointerii obinuii nc menin adresa memorie unde e obiectul utilizat, dac eliberarea memoriei nu se face corect, smart pointers pot automat detecta condiia c obiectul nu mai exist i s refuze accesul. Dei mecanismul e simplu, proiectarea de detaliu a clasei smart pointer ascunde mult funcionalitate.
52 /58
ablonul Container
Cnd un obiect are asociere 1-la-mai muli i dorim s mbuntim reuzabilitatea, o soluie este ca acea clas de la captul 1 s gestioneze un set de obiecte stocate ntr-un container (v. cursul despre tipare). Adugarea unui obiect container pentru a gestiona obiectele agregate nu rezolv n ntergime problema, deoarece adesea mai muli clieni doresc s acceseze simultan containerul. Pentru a rezolva problema, se folosesc iteratori n conjuncie cu containerele (in evidena poziiei din container a fiecrui client). Standard Template Library (STL) - parte a standardului ANSI C++ furniezeaz o varietate de containere i iteratori (v. cursul despre tipare). ablonul Container este foarte simplu, chiar dac un container n siner poate fi intern foarte complex. Participanii n cadrul unui ablon Container: Container gestioneaz colecia i furnizeaz operaiile de acces Iterator acioneaz ca un smart pointer i mediaz accesul de ctre Client (first, next, insertion, deletion etc.) la obiectele Parte. Client obiectele care doresc accesul la obiectele Parte gestionate de Container Parte obiectele gestionate de Container Parte inclusiv stocate de acesta
53 /58
ablonul Observer
Problema: este uzual situaia n care o singur surs de informaie acioneaz ca un server pentru mai muli clieni care trebuie s i actualizeze autonom datele cnd acestea se schimb. Pentru aplicaii n timp real cu date citite de senzori, problema este cum proiectm o modalitate eficient de notificare (anunare) a tuturor clienilor Soluia: ablonul Observer (sau PublishSubscribe) un singur obiect (Server) furnizeaz automat date pentru clienii si (Observers). Acestea sunt clase abstracte care au clase derivate (Concrete Server i Concrete Observer) care adaug comportamentul specializat pentru situaia concret de funcionare. Observerii se nregistreaz la server prin apelul metodei Subscribe() a acestuia i se dezaboneaz prin apelul metodei Detach() . Atunci cnd serverul primete un apel subscribe, creaz un obiect Notification Handle care include adresa obiectului. Politica de actualizare definete criteriile dup care datele sunt trimise la observer - periodic, episodic sau epi-periodic (amndou) .
54 /58
Observer cont. 1
ablonul Observer este util dac muli clieni vor s acceseze un singur obiect. ablonul simplific crearea acestor clieni deoarece dup ce acetia se nregistreaz, vor fi notificai asupra datelor, conform politicii de actualizare definite.
Entitile participante n ablon:

Server este o clas abstract care definete interfaa la care clasa abstract observer ader Folosete metoda Update() method a clasei Observer pentru a transmite valoarea ctre Observer. Metodele de interes ale clasei sunt: Subscribe(target address, policy) adaug obiectul indicat de target address la o list de notiificare prin crearea unui obiect NotificationHandle. Clasa derivat specific creat depinde de parametrul policy. Acesta are o valoare dintr-o enumerare updatePolicy care conine valorile episodic, periodic, epiPeriodic.
Detach(target address) dez-aboneaz ceea ce a fost transmis prin Subscribe() prin tergerea obiectului Notification Handle corespunztor obiectului cu adresa target address. Gimme() permite o interogare direct a valorii urmrite AcceptTick() este apelat de un obiect de asigurare a unei temporizri (precum timerele furnizate de sistemul de operare) care indic trecerea unui interval de timp sau contorizarea unei secvene de eevnimente. Acesta incrementeaz atributul CurrentTime . Atunci cnd aceast metod este apelat, serverul scaneaz lista de notificare alctuit din obiecte cu notificare periodic r Periodic Notification Handle la care valoarea trebuie actualizat. Concrete Server este o clas derivat din Server i o extinde cu datele propriu-zise de interes i metoda Acquire(): Acquire() preia datele concrete pentru server. Atunci cnd metoda este apelat, mesaje de date sunt trimise la toate obiectele din lista cu Episodic 55 /58 Notification Handles.
Observer cont. 2
Observer clasa abstract Observer apeleaz metoda Subscribe() a clasei Server pentru ca ulterior s fie notificat automat asupra datelor i metoda Detach() cnd nu mai dorete s fie la curent cu aceste date. Atre metoda Update(value) apelat de Server pentru pasarea valorii. Din punct de vedere logic, este o funcie callback (apel invers, napoi) Concrete Observer este o subclas a clasei Observer i adaug stocarea local n atributele dorite, precum i celelalte metode cerute de funcionarea dorit a clientului propriu-zis. Notification Handle este o referin local la un Observer mregistrat, deinut i gestionat de Server. Este creat atunci cnd un Observer apeleaz Subscribe() i este distrus cnd acesta apeleaz Detach(). Conine atributul Object Address, care este o referin la funcia Update() din Observer. Setul tutuor Notification Handles este utilizat ca list de notificare. Aceasta este utilizat de Server astfel nct acesta poate apela metodele Update() ale obiectelor Observer atunci cnd e cazul.
Episodic Notification Handle este o subclas a Notification Handle i genereaz o ierarhie separat de clase cu baza Notification Handle . Observers nregistai cu aceastp politic sunt actualizai cu date oridecteori aceste date se schimb. Periodic Notification Handle este o subclas a clasei Notification Handle i este utilizat pentru a notifica periodic Observers astfel nregistrai. Aceasta permite mbuntirea serviciilor clasei Observer n situaia pierderii sau coruperii de mesaje. Subclasa adaug atributele Period iTimeOfNextUpdate. Clasa Server scaneaz Periodic Notification Handles periodic i atunci cnd s-a scurs perioada de notificare, obiectul Observer referit este acutalizat i TimeOfNextUpdate is recalculat.
56 /58
ablonul
Model-View-Controller (MVC)
Este alctuit din setul de componente ortogonale: Model componenta de date i procesare specific a aplicaiei (business model) View cuprinde modul de afiare a rezultatelor Controller recepionez i proceseaz evenimentele din vizualizare Exemplu: ntr-un monitor ECG, btile inimii pot fi vizualizate/prezentate n mai multe moduri: iconografic, numeric, grafic, alarm, sunet. Modul de prezentare nu are consecine asupra modului de achiziie sau manipulare. Prin separarea acestei funcionaliti, un mic set de obiecte care colaboreaz i lucreaz mpreun pot s rezolve problema Este aplicabil n sistemele n timp real care au afiaje, n particular atunci cnd valorile trebuie controlate i afiate simultan. Este o form specializat de ablon Observer. Poate fi implementat prin utilizarea pointerilor sau a metodelor publish-subscribe din ablonul Observer. Dac obiectele se schimb dinamic (n timpul rulrii) sau dac obiectele Controller sau View s-ar putea s nu fie cunoscute la compilare, atunci abordarea cu subscriere este de preferat. Exemplu: o valv care este controlat de un buton cu valoare vizualizat sub form de deschidere pe ecran.
Exemplu: arhitectura document-view (v. cursul despre MFC) unde CDocument este clasa Model, metoda UpdateAllViews a acestei clase transmite actualizrile iar OnUpdate din vizualizarea derivat din CView trateaz actualizarea n fiecare vizualizare.
57 /58
Mulumesc pentru atenie aten ie !

12 UML Sabloane de Proiectare

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

12 UML Sabloane de Proiectare

Încărcat de

Drepturi de autor:

Formate disponibile

POOPOO - Vasile StoicuStoicu-Tivadar

Proiectarea orientat pe obiecte i

POOPOO - Vasile StoicuStoicu-Tivadar

Avantajele analizei i proiectrii orientate pe obiecte

POO - Vasile StoicuStoicu-Tivadar

Paii analizei i proiectrii orientate pe obiecte

POO - Vasile StoicuStoicu-Tivadar

POO - Vasile StoicuStoicu-Tivadar

UML. UML . Intro Introduc ducere ere

POO - Vasile StoicuStoicu-Tivadar

UML . Introduc Introducere ere

Obiectele colaboreaz pentru a asigura funcionalitatea dorit

UML. UML . Intro Introduc ducere ere

POO - Vasile StoicuStoicu-Tivadar

UML. UML . Intro Introduc ducere ere

POO - Vasile StoicuStoicu-Tivadar

UML. UML . Intro Introduc ducere ere

UML. UML . Intro Introduc ducere ere

UML. Intro UML. Introduc ducere ere Diagrame de clase

Exemplu: Relaii de Clas Fereastr

Exemplu: Relaii de Clas Senzor

POO - Vasile StoicuStoicu-Tivadar

UML. UML . Intro Introduc ducere ere

Diagrame UML i notaii

POO - Vasile StoicuStoicu-Tivadar

Analiza cerinelor cerinelor pentru sisteme n timp real

POO - Vasile StoicuStoicu-Tivadar

Analiza cerinelor - continuare

Subsistem Interfee Utilizator Cazuri de Utilizare pentru subsistem

Analiza cerinelor - continuare

Analiza cerinelor - continuare

Notaiile textuale identific condiiile iniiale, aciunile, activitile.

Analiza cerinelor - continuare

Extensii pentru Timp Real

POO - Vasile StoicuStoicu-Tivadar

Analiza cerinelor - continuare

Analiza cerinelor - continuare

Exemplu: Diagrama cazurilor de utilizare a unui Monitor ECG

POO - Vasile StoicuStoicu-Tivadar

Analiza cerinelor - continuare

Definirea structurii obiectelor

Definirea structurii obiectelor

Identify causal objects Identify services (passive Identify realworld items

Identify physical devices

Identify key concepts

Strategi Strategii i cheie pentru identificarea obiectelor

POO - Vasile StoicuStoicu-Tivadar

Definirea structurii obiectelor

POO - Vasile StoicuStoicu-Tivadar

Definirea structurii obiectelor Asocierile

Definirea structurii obiectelor

POO - Vasile StoicuStoicu-Tivadar

Definirea structurii obiectelor

Definirea structurii obiectelor

Definirea structurii obiectelor

Definirea comportamentului obiectelor

Comportament de stare (determinat de stri -state-driven, reactiv)

POO - Vasile StoicuStoicu-Tivadar

Definirea comportamentului obiectelor

Definirea comportamentului de stare al obiectelor

Temporizator re-armabil nerepetititv

Definirea comportamentului obiectelor

Definirea comportamentului obiectelor Exemplu