8 UML Pentru Sisteme in Timp Real. Sabloane de Proiectare

FISFIS- Vasile StoicuStoicu-Tivadar
1 /58
CAPITOLUL 8.
Proiectarea orientat pe obiecte i
Unified Modelling Language
(UML)
ABLOANE DE PROIECTARE
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
FIS - 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. Introducere
Obiecte. Exemple.
6 /58
UML . Introducere
Comportament
Obiectele colaboreaz pentru a asigura

funcionalitatea dorit
7 /58
UML. Introducere
Clase. Exemple
8 /58
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
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
UML. Introducere
Tipul de asociere
Motenire(Gen-Spec)
Agregare
Compoziie
Clas
Subclas
ntreg
ntreg
Asociere unidirecional
Client
Asociere bi-direcional
Dependen
Simbol de asociere
Client
Clas
Superclas
Parte
Parte
Furnizor
B
Furnizor
11 /58
UML. Introducere
Diagrame de clase
Exemplu: Relaii de Clas Fereastr
Exemplu: Relaii de Clas Senzor
12 /58
UML. Introducere
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 - 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 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 de Secven
-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
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
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

coluri rotunjite numite stri.
O stare este o condiie de existen a unui
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.
Exemplu: main de stare pentru cazul

de utilizare Pozitionare Telescop al
unui sistem de comand a unui
telescop
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
Exemplu: Diagrama cazurilor
interaciunile (fluxurile)
de utilizare a unui Monitor
secvenele de evenimente i date
ECG
posibilele variaiuni
FIS - Vasile Stoicu--Tivadar
FIS - Vasile Stoicu Tivadar
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: 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
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.
Strategii cheie
pentru
identificarea
obiectelor
Cel mai bune stfel
de strategii:
Strategy
Description
Underline the
noun
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 causal
objects
Identify the sources of actions, events, and messages;

includes the coordinators of actions.
Identify
services
(passive
Identify realworld items
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.
Identify
physical
devices
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."
Identify key
concepts
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 compozi
compoziia sunt forme specializate de
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.
Dependen
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
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 clientclient-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 PeerPeer-toto-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
27 /58

Agregarea i Compoziia
Agregarea
gregarea este un tip special de asociere care implic proprietatea logic sau fizic.
Unii autori prefer termenul agregare
agregare, alii, termenul parte/
parte/ntreg.
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.
Compozi
Compoziia 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.
29 /58

Generalizarea
Clasa cea mai sus n ierarhie se numete
printe,
rinte, generalizare,
generalizare, de baz sau
superclas.
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:
mo
motenirea (o sublcas are toate atributele, operaiile, asocierile i dependenele superclasei sale)
Subclasa poate s specializeze
specializeze (subclasa poate s redefineasc polimorfic o operaie)
extind
xtind proprieti motenite (subclasa poate s adauge noi atribute, operaii, asocieri .a.m.d.)
substitutabilitatea
substitutabilitatea (o instan a unei subclase poate fi substituit totdeauna cu o instan a superclasei
sale, fr a nclca semantica modelului Principiul de Substitu
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)
30 /58

Exemple de specializare
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);
};
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 cat: public Animal {

public:
void speak (void) { cout << Miew ! << endl; } ;
void ClawFurniture(long ClawLength);
void SnubOwner(void);
};
Clas
Clas abstract acea clas care nu poate fi instaniat direct (conine cel puin o funcie virtual
pur)
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
Temporizator re-armabil
nerepetititv
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
de descriptorul (eticheta) tranziiei printr-un slash.
care ncep de la starea de pornire i se termin la
starea int. Tranziiile au de obicei asociate
nume de evenimente declanatoare urmate de
aciuni nterprinse dac se realizeaz tranziia.
33 /58

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 pseudopseudo-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.
34 /58

Exemplu
Stimulator cardiac
Enun
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
Exemplu
Stimulator
Cardiac continuare 1
Acest enun de
problem poate fi
transpus ntr-un
model simplu de
clase:
36 /58

Exemplu
Exemplu Stimulator Cardiac - 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
Exemplu de Stimulator Cardiac - continuare 3
Comportamentul:
Comportamentul
Modelul de stare al unitii de comunicaii
Model de stare al compartimentelor inimii
38 /58

Exemplu
Exemplu de Stimulator Cardiac - continuare 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.
39 /58

Diagrame de Secven
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).
40 /58

Definirea 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
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)
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) :
node* p;
node current_node;
public:
node* next(void);
node* previous(void);
};
42 /58

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:
Poate unii clieni ar dori s caute

sau mai mult, s reporneasc o
cutare :
node* p;
node current_node;
public:
node* next(void);
node* first();
node* last();
node* find(node &n);
};
node* p;
public:
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* first();
node* last();
node* find(node &n);
};
43 /58

Strategii pentru definirea operaiilor
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.
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 FIS) 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
(implementrile 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/
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
Exemplu:
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.
ablonul e reprezentat ca un oval

punctat din care sgei punctate
arat ctre clasele din cadrul
ablonului
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 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
Parte obiectele gestionate de Container
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 !

8 UML Pentru Sisteme in Timp Real. Sabloane de Proiectare

Încărcat de

Informații document

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

8 UML Pentru Sisteme in Timp Real. Sabloane de Proiectare

Încărcat de

Drepturi de autor:

Formate disponibile

FISFIS- Vasile StoicuStoicu-Tivadar

FISFIS- Vasile StoicuStoicu-Tivadar

Avantajele analizei i proiectrii

FIS - Vasile StoicuStoicu-Tivadar

Paii analizei i proiectrii orientate pe

asamblarea i testarea sistemului

FIS - Vasile StoicuStoicu-Tivadar

FIS - Vasile StoicuStoicu-Tivadar

FIS - Vasile StoicuStoicu-Tivadar

Obiectele colaboreaz pentru a asigura

FIS - Vasile StoicuStoicu-Tivadar

Un exemplu de diagram simpl

FIS - Vasile StoicuStoicu-Tivadar

Exemplu: Relaii de Clas Fereastr

Exemplu: Relaii de Clas Senzor

FIS - Vasile StoicuStoicu-Tivadar

FIS - Vasile StoicuStoicu-Tivadar

Analiza cerinelor pentru

Exemplu: cteva cazuri de utilizare ale unui

FIS - Vasile StoicuStoicu-Tivadar

Analiza cerinelor - continuare

Subsistem Interfee Utilizator

Analiza cerinelor - continuare

Analiza cerinelor - continuare

Liniile verticale de instan

Notaiile textuale identific condiiile iniiale, aciunile,

Analiza cerinelor - continuare

Extensii pentru Timp Real

FIS - Vasile StoicuStoicu-Tivadar

Analiza cerinelor - continuare

O diagram de stare conine dreptughiuri cu

Exemplu: main de stare pentru cazul

Un Clasificator este o metaclas n UML, care are proprietatea c are asociat o

Analiza cerinelor - continuare

Analiza cerinelor - continuare

Definirea structurii obiectelor

Definirea structurii obiectelor

Used to gain a first-cut object list, the analyst underlines

Identify the sources of actions, events, and messages;

Identify the targets of actions, events, and messages,

Physical devices include the sensors and actuators

Key concepts may be modeled as objects. Bank

Walk through scenarios using the identified objects.

FIS - Vasile StoicuStoicu-Tivadar

Definirea structurii obiectelor

Asocierile sunt structurale, nsemnnd c trebuie s fie

Exemplu: o diagram de clase cu clasele

FIS - Vasile StoicuStoicu-Tivadar

Definirea structurii obiectelor

FIS - Vasile StoicuStoicu-Tivadar

Definirea structurii obiectelor

Definirea structurii obiectelor

Definirea structurii obiectelor

class cat: public Animal {

Definirea comportamentului obiectelor

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

FIS - Vasile StoicuStoicu-Tivadar

Definirea comportamentului obiectelor

Definirea comportamentului de stare al

n metodologiile orientate pe obiect, elementele

Definirea comportamentului obiectelor

Definirea comportamentului obiectelor

FIS - Vasile StoicuStoicu-Tivadar

Definirea comportamentului obiectelor