CAP.
4 BEHAVIORAL
MODELING
1. Modelarea comportamentului.
Definire
descrie logica (comportamentul) interna a proceselor din sistemul
informational
altfel spus, se modelează aspectele dinamice ale sistemului
spre deosebire de modelarea comportamentului,
modelarea functionala descrie comportamentul extern al
sistemului, adica vazut din exterior, din perspectiva
utilizatorului
modelarea structurala descrie structura interna (statica) a
sistemului, adica clasele de obiecte care implementeaza
functionalitatile aplicatiei si relatiile dintre clase
se utilizeaza trei tipuri de diagrame
diagrame de interactiune - arată cum interactionează obiectele
aplicatiei prin transmiterea de mesaje pentru a implementa
cerinţele functionale
diagrame de secvenţă – pune accent pe succesiunea în
timp a mesajelor
diagrame de comunicare (colaborare) – pune accent pe
legăturile dintre clasele de obiecte
Diagrama de stari (state machine diagram)– evidentiaza
starile unui obiect si comportamentul diferit al acestuia in
2. Diagrama de secvenţă
Elementele componente principale:
Obiecte - se reprezintă prin dreptunghiuri, plasate orizontal, în partea
de sus a diagramei, în care sunt scrise numele acestora si a clasei.
Linia vieţii - durata de existenţă a obiectelor. Se reprezintă cu o linie
verticala intrerupta ce pleaca de la fiecare obiect.
Mesajele = elementele de comunicare dintre obiecte. Ele se reprezintă
prin linii cu săgeţi ce unesc liniile de viaţă ale obiectelor.
Mesajele pot fi însoţite de condiţii, pentru transmiterea sau nu a
unui mesaj şi de parametri
Se poate reprezenta un mesaj transmis de un obiect către el însuși
Mesajele de răspuns pot fi redate printr-o linie întreruptă
Diagrama de secvente trebuie citita de la stanga la dreapta si de sus in
jos
2. Diagrama de secvenţă
Obiectul
Mesaj Obj2 de
schimbat tipul Class2
Mesaj
intre 2
de
sd Class ModelDataModeling obiecte
creare
Obj1 :Class1 Obj2 :Class2 obiect
Actor1
Object2
create()
actiune()
[test]:metoda(param1) :
valReturn
*[[test loop]]:altaMetoda()
autoInvocare()
Linia Mesaj
vietii Activarea reflexiv
unui unui obiect
obiect (executa
ceva)
2. Diagramele de secvenţă. Exemplu de transpunere in
cod
2. Diagramele de secvenţă. Tipuri de mesaje
Mesajele pot fi clasificate şi descrise astfel:
mesaje sincrone: obiectul care transmite mesajul
aşteaptă terminarea prelucrării indicate de mesaj
(metoda invocate) de catre obiectul apelat;
mesaje asincrone: obiectul transmitator nu asteapta
terminarea procesarii indicate de mesaj de catre obiectul
apelat si poate iniţia un alt mesaj.
mesaje simple: mesaje pentru care nu se specifică
proprietatea de sincronizare.
mesaj de raspuns (return)
2. Diagramele de secvenţă. Reprezentarea structurilor
de control
Frame – se utilizeaza pentru reprezentarea structurilor de
control alternative sau repetitive
Se specifica un operator/eticheta si o expresie logica
Cei mai utilizati operatori
Frame Operator Meaning
alt Se reprezinta o structura de control alternativa.
loop Se reprezinta o structura repetitive in care executia unui fragment se reia atat
timp cand expresia logica este adevarata. Se poate reprezenta si executarea
repetata a unui fragment cu un numar dat de iteratii – loop(n).
opt Executia optionala a fragmentului, doar daca expresia logica este adevarata
par Se indica executarea in paralel a fragmentelor
region Se foloseste pentru a indica faptul ca un singur fir (thread) poate fi executat la
un moment dat (opus fata de operatorul “par”).
2. Diagramele de secvenţă
Exemple de utilizare a frame-urilor
2. Diagramele de secvenţă. Reprezentarea
Se creeaza mai multe diagrame de secvență
polimorfismului
o diagramă arată mesajul polimorfic către obiectul superclasă sau
interfață
câte o diagramă pentru fiecare manifestare a polimorfismului
2. Diagramele de secvenţă. Alte reprezentari ale
obiectelor
Boundary/interface elements: software elements such as screens, reports,
HTML pages, or system interfaces that actors interact with.
Control/process elements (controllers): These serve as the glue between
boundary elements and entity elements, implementing the logic required to
manage the various elements and their interactions. Often implemented using
objects, but simple ones using methods of an entity or boundary class.
Entity elements
2. Diagramele de secvenţă.
o diagramă de secvenţă poate fi construita pentru:
Recomandări.
fiecare eveniment–system (system event) identificat intr-un caz
de utilizare
un system event este un punct in executia unui caz de
utilizare in care aplicatia trebuie sa execute un task
Un scenariu al unui caz de utilizare poate avea mai multe astfel
de evenimente – validarea clientului, obtinerea unei liste a
facturilor neachitate ale unui client, adaugarea facturii
Se justifica in cazul evenimentelor complexe, care presupun
interactiunea mai multor obiecte
fiecare scenariu al unui caz de utilizare – se recomanda in
majoritatea situatiilor
Permite o mai buna intelegere si o interpretare mai usoara
Are dezavantajul modelarii redundante a pasilor comuni mai
multor scenarii
fiecare caz de utilizare – rareori recomandata
Poate fi prea complexa – face dificila interpretarea si
intelegerea ei
greutăţile în începerea unei diagrame de secvenţă pot fi explicate şi
printr-o alegere incorectă a cazurilor de utilizare şi o analiză
incompletă a sistemului;
2. Diagramele de secvență. Alte
Diagrama de secvenţă lautilizări
nivelul sistemului (SSD – System
Sequence Diagram):
este construită pentru un scenariu al unui caz de utilizare;
evidențiază evenimentele generate de actori în interacțiunea
lor cu sistemul,ordinea evenimentelor și răspunsurile
sistemului;
sistemul este tratat ca o cutie neagră – accentul este pus pe
CE face sistemul, fără a ne interesa CUM face el;
se recomandă construirea unei SSD pentru scenariul
principal al fiecărui caz de utilizare și pentru scenariile
alternative și de excepție mai complexe
2. Diagramele de secvenţă. Exemplu 1
2. Diagramele de secvenţă. Exemplu 2
2. Diagramele de secvenţă. Imprumutul unei
carti
2. Diagramele de secvenţă. Restituirea unei
carti
3. Diagramele de
comunicare
se ia în considerare spaţiul şi nu factorul timp (precum in DSecv)
pune in evidentă în mod explicit legăturile dintre clasele de obiecte
sugerează o formă de navigare și vizibilitate între clasele de obiecte
sugerează o asociere navigabilă între clase
mesajele condiționale sunt evidențiate prin [expresie_logica] atasata
mesajului
este obligatorie numerotarea mesajelor pentru a se indica secvenţa
(temporala) acestora
3. Diagramele de
Mesajele comunicare
alternative sunt evidentiate prin atasarea unei litere la
numarul de secventa al mesajului – 1.a, 1.b ...
Mesajele iterative sunt evidentiate prin atasarea “*” la numarul
de ordine al mesajului
3. Diagrama de comunicare (DC) vs
diagrama de secvențe (DS)
Cele doua tipuri de diagrame sunt similare, iar instrumentele CASE pot
genera automat una din cealalta.
3. Diagrama de comunicare
(DC) vs diagrama de secvențe
(DS)
Alegerea tipului de diagramă depinde de preferințele fiecăruia
DS sunt mai potrivite pentru a urmări secvența fluxurilor de mesaje
prin citirea de sus în jos
DC este mai apropiata de diagrama de clase (corespondenta cu
diagrama de clase este mai directa) si arata legaturile dintre obiecte.
DC permit utilizarea mai eficientă a spațiului pentru construirea
diagramelor
Sunt recomandate la aplicarea ”UML as a sketch”
4. Legăturile diagramelor de
interactiune cu alte diagrame UML
diagrama cazurilor de utilizare
DS poate fi întocmită pentru fiecare CU, doar pentru un
scenariu al unui CU sau doar pentru un eveniment din scenariu
diagrama claselor de obiecte (DCO)
obiectele incluse în DS au corespondent în clasele din DCO
interacţiunile din DS privesc metodele implementate în DCO
diagrama de activităţi
activările unui obiect reprezintă punctele de legătură cu DST şi
DA
diagrama de stări - legatura nu este foarte directa, dar exista!
nu se poate construi DS dacă anterior nu sunt create DCU şi DCLs
5. Interaction Overview Diagram (IOD)
Este o forma a diagramei de activitati in care nodurile (activitatile) sunt
reprezentate sub forma diagramelor de interactiune – diagrame de
secvente sau diagrame de colaborare
Ofera o imagine de ansamblu asupra fluxului de control si a
interactiunilor dintre componentele/obiectele aplicatiei
Arata modul in care componentele/obiectele aplicatiei comunica si
colaboreaza in vederea atingerii unui obiectiv (implementarea unei
functionalitati)
Introduce doua elemente noi:
Interaction Occurrence – face referinta la o alta diagrama de
interactiune
Interaction Element – diagrama de interactiune este afisata direct
in IOD, intr-un frame
Beneficii ale utilizarii IOD:
ajuta la intelegerea mai usoara a sistemelor complexe
Asigura o mai buna colaborare intre membrii echipei de dezvoltare
prin faptul ca faciliteaza intelegerea comportamentului sistemului
imbunatateste eficienta managementului schimbarii prin
5. Interaction Overview Diagram (IOD).
Exemplul
IOD de mai jos arata fluxul de 1
control al interactiunilor specifice unei
platforme de cumparaturi on-line.
Exemple de interactiuni: cautarea unui articol, adaugarea sau
stergerea in/din cosul de cumparaturi, etc.
5. Interaction Overview Diagram (IOD).
Exemplul 2
In acest exemplu
se regasesc
Interaction
Occurrence si
Interaction
Element
5. Interaction Overview Diagram (IOD)
Pot fi combinate si mai multe diagrame de interactiune( fara a
se utiliza diagrama de activitati):
6. Diagrama de stari (DSt). Introducere
Titulaturi întâlnite:
State machine diagram
State chart diagram
State diagram
DSt descrie comportamentul unui obiect de-a lungul vietii sale,
precum si modul in care obiectul raspunde la diferite evenimente
prin schimbarea starii
Diagrama de stări prezintă:
stările prin care trec obiectele dintr-o clasa
tranzițiile care au loc între stări
evenimentele care determină tranziţiile între stări
acţiunile ataşate stărilor sau tranziţiilor între stări
6. Diagrama de stari. Introducere
Există 2 categorii de obiecte d.p.d.v. al comportamentului:
State-independent object – obiectul răspunde în același fel pentru fiecare
eveniment/mesaj primit, indiferent de starea sa
Un obiect poate fi state-independent relativ la un mesaj
State-dependent object – reacționează în mod diferit la acelasi
eveniment, în funcție de starea în care se află
DSt se întocmește doar pentru obiectele complexe:
al căror comportament diferă de la o stare la alta
Exemplu - starile si comportamentul unui obiect de tip Ușa
Contraexemplu – obiectul Student și atributul Nume
Elementele componente ale unei diagrame a stărilor de tranziţie seamănă cu cele ale
unei diagrame de activităţi:
tranziţii (reprezentate grafic asemănător cu fluxurile)
stări (reprezentate grafic asemănător cu acţiunile)
noduri iniţiale si finale
noduri de decizie, noduri de bifurcare (Fork)/jonţiune (Join)
6. Diagrama de stari. Stări
O stare este caracterizată de valorile proprietăţilor unui
obiect şi de mulţimea mesajelor care pot fi acceptate de
către acest obiect la un moment dat.
Exemplu 1 - stările unei imobilizări corporale
depozitat
in funcţiune
in conservare
amortizat – atunci când ValoareAmortizata =
ValoareInventar
casat
un obiect aflat în starea CASAT nu poate primi
mesajele ÎnregistrareAmortizareLunară, Casare
un obiect poate primi mesajul
ÎnregistrareAmortizareLunară doar dacă se află
în starea in funcţiune
Exemplu 2 – stările unui obiect student ?
Stările de interes ale unui obiect sunt acelea care
presupun un comportament diferit de la o stare la
6. Diagrama de stari. Stări
Starea unui obiect este reprezentată prin simbolul:
În simbolul unei stări pot fi incluse elementele: Denumire stare
Entry / acţiune
numele stării Do : acţiune
Exit / acţiune
variabilele de stare
acţiunile interne – trei categorii
de intrare (Entry) – executată imediat după intrarea în
starea respectivă
de ieşire (Exit) – executată înainte de ieşirea din starea
respectivă
executate pe parcursul stării (Do) – ele pot avea asociate
evenimente declansatoare
exemplu de stare – obiectul de tip Imobilizare
6. Diagrama de stari. Tranziții
Tranziţia de la o stare la alta a unui obiect este determinată de
apariția unui eveniment (declanșator)
Unei tranziții între stări îi pot fi asociate:
Eveniment declanșator (trigger)
Condiție (guard condition) – o expresie logică ce trebuie să aibă
valoarea adevărat pentru ca tranziția să fie realizată
Acțiune (effect) – operațiunea care va fi invocată imediat asupra
obiectului ca urmare a tranziției între cele două stări
are semantică similară cu acțiunea internă de tip Entry sau Exit
dacă există mai multe tranziții de intrare/ieșire într-o/dintr-o
stare care au asociată acceași acțiune, acțiunea va fi
reprezentată ca internă Entry/Exit
Notația UML pentru reprezentarea unei tranzitii
6. Diagrama de stari. Tranziții
Tranzitie reflexiva (Self-transition)
• Este utila atunci cand tranzitia are
asociata o actiune (ea trebuie executata,
chiar daca obiectul ramane in aceeasi
stare
Exemple de tranziții:
Obiectul de tip MijlocFix
Obiectul de tip ComandaClient
6. Diagrama de stari. Tranziții
tipuri de evenimente declanşatoare a unei tranziţii între stări:
de timp – după un anumit interval de timp se declanşează
tranziţia – AFTER
exemplu: după 30 de zile de la livrare, factura devine scadentă
de modificare (change) - apar ca urmare a modificării valorii
unui atribut - WHEN
exemplu: la actualizarea valorii achitată, dacă
ValoareFactura=ValoareAchitata, atunci factura ajunge în starea
achitată
semnal (signal) – ca urmare a unui mesaj primit din partea altui
obiect.
exemplu: înregistrarea facturii presupune ca obiectul LIVRARE
să transmită un mesaj-semnal obiectului COMANDA prin care
aceasta va trece în starea Onorată
6. Diagrama de stari. Tranziții
tranziţia poate avea asociată o condiţie (guard condition) - o
expresie logică
Exemple de condiții de tranziție:
trecerea Comenzii din starea Primită în starea Aprobată
guard condition: [Sold+ValoareComanda <= LimitaCredit]
Trecerea Facturii în starea Achitată
guard condition: [ValoareFactura = ValoareAchitata]
Condiția poate fi descrisă:
informal – text liber – mai ales in faza de analiză
formal – un limbaj de programare sau OCL – pentru generarea
automată a codului
6. Diagrama de stari. Stari vs subclase
Uneori se poate
face confuzie intre
starile unui obiect si
subclasele clasei
din care provine
obiectul
6. Diagrama de stari. Exemplul 1
Starile obiectului de tip Comanda
6. Diagrama de stari. Exemplul 2
Vezi comentarii la
[Link]
.htm
6. Diagrama de stari. Exemplul 3
Starile obiectului Book in sistemul unei biblioteci
6. Diagrama de stari. Exemplul 4
6. Diagrama de stari. Exercitiu
Care este valoarea lui x dupa aparitia secventei de evenimente :
e4 e2 e4 e1
6. Diagrama de stari. Alte exemple
Achiziţie – plecând de la referate de necesitate
Factură (neincasata, incasata total, incasata partial,
neacceptata la plata, stornata)
6. Diagrama de stari. Legăturile cu
alte diagrame UML
Diagrama de activităţi (DAct)
o Starile si tranzitiile unui obiect poate fi evidentiate in DAct
sub forma fluxului de obiecte
o DSt foloseste aceleasi notatii (simboluri) ca DAct
Diagrama de clase (DCls
o Clasa pentru care se construieste DSt trebuie sa existe in
DCls
o Actiunile asociate tranzitiilor sau starilor obiectului trebuie
fie implementate ca metode in DCls
Diagrama cazurilor de utilizare (DCU)
o evenimentele declansatoare si tranzitiile intre stari sunt
descrise in detalierea cazurilor de utilizare
Diagrama de secvenţe (DSecv)
o DSt surprinde comportamentul unui singur obiect descris in
mai multe cazuri de utilizare
o DSecv prezinta comportamentul mai multor obiecte
specific unui singur caz de utilizare
Webografie
[Link]
l
[Link]
2_sequencediagram.html
[Link]
m
[Link]
.htm
[Link]
[Link]#water-phase-diagram
[Link]
html