1.

Modelarea funcţionalităţilor sistemelor software

1.1. Diagrama cazurilor de utilizare
1.1.1. Identificarea actorilor
1.1.2. Identificarea use case-urilor
1.1.3. Documentarea use case-urilor
1.1.4. Relaţiile dintre use case-uri
1.1.5. Specificarea cerinţelor non-funcţionale
1.2. Diagrama de activităţi

2. Modelarea statică a sistemelor software – diagrama de clase

2.1. Modelarea statică a domeniului problemei
2.2. Modelarea statică a contextului problemei
2.3. Modelarea claselor externe
2.4. Structurarea claselor şi obiectelor
2.4.1. Clase şi obiecte de tip limită
2.4.2. Clase şi obiecte entitate
2.4.3. Clase şi obiecte de control
2.4.4. Clase şi obiecte de tip logica aplicaţiei

3. Modelarea dinamică a sistemelor software - diagramele de secvență și de comunicare, diagrama

de stări
3.1. Modelarea interacţiunilor dinamice
3.1.1. Modelarea interacţiunilor independente de stare
3.1.2. Modelarea interacţiunilor dinamice dependente de stare
3.2. Diagrama de stări
1. Modelarea funcţionalităţilor sistemelor software -
diagrama cazurilor de utilizare + diagrama de activităţi

1.1. Diagrama cazurilor de utilizare

Actori – entităţi exterioare sistemului
 utilizatori (persoane), echipamente hardware, alte programe

Use case-uri – secvenţe de interacţiuni între unul sau mai mulţi actori
şi sistem
 fiecare interacţiune constă într-o intrare de la actor urmată de un
răspuns al sistemului
 un use case este iniţiat întotdeauna de o intrare de la un actor

Relaţii - exprimă interacţiuni între use case-uri, între actori şi între use
case-uri şi actori
 asociere, dependenţă şi generalizare
Actorii caracterizează entităţile exterioare sistemului, care interacţionează
cu acesta

Actorii pot fi:

Utilizatori (persoane);

Sisteme externe;

Dispozitive I/O (în special în sistemele încorporate de timp real – sistemul
interacţionează cu mediul extern prin intermediul senzorilor sau elementelor de
execuţie);

Timere.

Actorii pot fi împărţiţi din punctul de vedere al iniţierii sau participării la un

use case în:

Actori primari - iniţiază use case-uri. Use case-ul este iniţiat de o intrare
provenită de la actorul primar la care sistemul trebuie să răspundă;

Actori secundari - participă la realizarea unui use-case.
Obs.:

un actor primar pentru un use-case poate deveni actor secundar în alt use-case;

cel puţin un actor trebuie să recepţioneze date de la un use-case; în mod
obişnuit, acesta este actorul primar.
1.1.1. Identificarea actorilor

Un actor uman utilizează dispozitive I/O standard (tastatură, display,

mouse) sau dispozitive I/O neuzuale (ex. senzori) pentru a
interacţiona fizic cu sistemul

persoana este actor iar dispozitivele I/O nu sunt actori, deci actorul este
utilizator final

Un actor de tipul sistem extern iniţiază (ca actor primar) un use case sau
participă (ca actor secundar) într-un use-case

Un actor de tipul dispozitiv I/O apare atunci când nu este implicat un

utilizator uman.

Uzual, un astfel de actor interacţionează cu sistemul prin intermediul
unui senzor

Un actor de tipul timer iniţiază periodic use case-uri

1.1.2. Identificarea use case-urilor

 Pentru identificarea cazurilor de utilizare se pleacă de la actori şi

interacţiunea acestora cu sistemul.
 Fiecare use case descrie o secvenţă de interacţiuni între actor şi
sistem.

un use case specifică o funcţionalitate a sistemului.
 Este de evitat o descompunere funcţională în care use case-uri
„mici” descriu funcţii „mici” ale sistemului;

se încearcă descrierea unei secvenţe de evenimente ce produc un
rezultat folositor actorului.

Fiecare use case descrie un număr de scenarii şi modelează:

 o secvenţă principală – interacţiunile obişnuite între actor şi sistem;
 o serie de secvenţe alternative – tratează cazurile de eroare;
1.1.3. Documentarea use case-urilor
Nume use case: use case-urile au nume diferite.
Scurtă descriere: una sau două propoziţii
Dependenţe: secţiune opţională; se precizează use case-urile care includ sau extind use
case-ul descris.
Actori: se precizează actorul primar care iniţiază use case-ul şi actorii secundari care
participă în use case (dacă există).
Precondiţii: condiţii ce trebuie să fie adevărate la iniţierea use case-ului; ex: în starea
“idle”, ATM-ul afişează un mesaj.
Descrierea secvenţei principale: se descrie secvenţa cea mai uzuală de interacţiuni între
actor şi sistem; descrierea este de forma: intrare de la actor – răspuns al sistemului.
Descrierea secvenţelor alternative: pot exista mai multe secvenţe alternative pentru
aceeaşi secvenţă principală; ex: în cazul în care se doreşte retragerea de numerar dar
clientul nu dispune de fonduri suficiente, se afişează un mesaj şi se eliberează cardul.
Cerinţe non-funcţionale: se descriu cerinţele non-funcţionale cum ar fi performanţele
sistemului şi cerinţele de securitate.
Postcondiţie: condiţie ce trebuie să fie adevărată la terminarea use case-ului (din
perspectiva acestuia) dacă s-a urmărit secvenţa principală; ex. : fondurile au fost
retrase.
Probleme de rezolvat: de-a lungul dezvoltării, se marchează eventualele probleme care
trebuie discutate cu utilizatorii sistemului.
1.1.4. Relaţiile dintre use case-uri
Relaţia de dependenţă modelează două situaţii:

cazul în care un use case foloseşte funcţionalitatea oferită de un alt use
case - dependenţa de tip include;

există variante ale aceluiaşi use case – dependenţa de tip extend.

Use case-urile de incluziune identifică secvenţe comune de interacţiuni în

diverse use case-uri, care apoi pot fi extrase şi reutilizate.

în general se defineşte doar după o primă iteraţie în care se stabilesc câteva use case-uri

nu este necesar să aibă un actor specific

Relaţii de dependenţă de tip extend modelează căile alternative pe care le

poate lua un use case
 Extinderea unui use case se realizează pentru:

a arăta o parte opţională a unui use case de bază care este executată doar în anumite condiţii;

a modela căile alternative sau prea complexe.
 Este posibil ca un use case să extindă mai multe use case-uri de bază sau ca un use case
de bază să fie extins prin mai multe use case-uri extinse.
 Punctele de extensie specifică acele puncte din use case-ul de bază în care se realizează
extensia.
1.1.5. Specificarea cerinţelor non-funcţionale

Specificarea se face într-o secţiune distinctă a descrierii unui use case,

asemănător modului în care se face specificarea secvenţelor
alternative.
În cazul în care cerinţele non-funcţionale se aplică unui grup de use case-
uri legate între ele, specificarea se va face pentru un pachet use case.

1.1.6. Pachete Use case grupează use case-uri legate între ele

Se folosesc în cazul sistemelor de dimensiuni mari.

Pachetele modelează subseturi de funcţionalităţi ale sistemului.

Use case-urile se pot grupa în pachete funcţie de actorii principali care le utilizează.
1.2. Diagrama de activităţi

Descrie fluxul de control şi secvenţierea între activităţi

Un model use case poate fi descris cu o diagramă de activităţi

 Se modelează secvenţa principală şi toate secvenţele alternative.
 Se poate utiliza pentru a furniza o descriere mai precisă a unui use case.

poate descrie secvenţierea între use case-uri, punând în evidenţă secvenţierea
activităţilor.
 2. Modelarea statică a sistemelor software
2.1. Modelarea statică a domeniului problemei
 Se modelează clasele fizice, clasele entitate și relațiile dintre
acestea

Clase fizice sunt clase ce au caracteristici fizice şi includ:
 dispozitive fizice ( în special în aplicaţiile referitoare la sistemele încorporate);
 utilizatori;
 sisteme externe;
 timere.

Clasele entitate sunt clase conceptuale, adesea persistente, conţinând în
special informaţii despre sistem.

2.2. Modelarea statică a contextului problemei

 Diagrama de context a sistemului precizează graniţele dintre sistem
(hardware şi software) şi mediul extern.
 Diagrama de context a sistemului software modelează graniţele dintre
sistemul software şi mediul extern care include şi hardware-ul.

poate fi determinată prin modelarea statică a claselor externe care interacţionează cu sistemul

se poate determina de asemenea plecând de la use case-uri luând în considerare actorii şi
dispozitivele pe care aceştia le utilizează în interacţiunea cu sistemul
 În general, în dezvoltarea diagramelor de context, se va preciza mai întâi
diagrama de context hardware/software şi apoi cea software.
 2.3. Modelarea claselor externe
interacţionează cu sistemul sistemul interacţionează cu alte
software prin dispozitive I/O sisteme cărora le trimite sau de
specifice aplicaţiei la care primeşte date

interacţionează cu sistemul
există acţiuni în sistem iniţiate
software prin dispozitive I/O
funcţie de anumite momente de
standard
timp

Fig. 18. Clasificarea claselor externe cu ajutorul stereotipurilor

Clasele utilizator extern şi sistem extern sunt Clasele dispozitiv extern şi timer extern fac
clase externe sistemului total parte din sistemul total dar sunt externe
(hardware/software). sistemului software.
 2.4. Structurarea claselor şi obiectelor
încapsulează informaţii şi furnizează
acces către acestea; poate fi accesat realizează coordonarea
de un obiect serviciu unei mulţimi de obiecte
necesare când se
doreşte separarea logicii
interfaţarea şi aplicaţiei de datele
comunicarea cu mediul manipulate
extern şi pot fi

realizează coordonarea
altor obiecte

interfaţa cu
activate de un prin execuţia unor furnizează reguli
utilizatorul
timer extern diagrame de stare de operare
uman
furnizează controlul sisteme de timp real,
şi secvenţierea aplicaţii inginereşti
interacţiunilor sale
comunicarea cu cu alte obiecte
recepţionează intrări furnizează servicii
şi furnizează ieşiri un sistem extern către obiecte client
dispozitivelor
hardware I/O
2.4.1. Clase şi obiecte de tip limită
 Clasele limită sunt clase din interiorul sistemului care
interacţionează cu clasele externe.
 Fiecare clasă externă interacţionează cu sistemul prin intermediul
unei clase limită.
 În general, între clasele externe şi clasele limită există asocieri
unu-la-unu

Tabelul 1. Corespondenţa între clasele externe şi clasele limită

Clasă externă Clasă limită

utilizator extern interacţiune utilizator
sistem extern proxy
dispozitiv extern dispozitiv intrare ieşire limită
dispozitiv de intrare extern intrare
dispozitiv de intrare extern ieşire
dispozitiv de intrare/ieşire extern intrare/ieşire
timer extern timer
2.4.2. Clase şi obiecte entitate

Un obiect entitate stochează informaţii şi este o instanţă a unei

clase entitate
 atributele şi relaţiile cu alte clase entitate se determină în faza
modelării statice

Obiectele entitate stochează date şi acordă acces limitat la acestea
prin operaţiile pe care le furnizează.

Există situaţii în care un obiect entitate are nevoie de a accesa alte
obiecte entitate pentru a modifica informaţiile pe care le
încapsulează.

În general informaţiile încapsulate sunt stocate în fişiere sau în
baze de date ⇒ obiectele entitate sunt persistente
 În cazul aplicaţiilor de timp real, obiectele entitate sunt stocate în
memoria principală
2.4.3. Clase şi obiecte de control

Obiectele de control de tip coordonator determină când şi în ce ordine
participă unele obiecte la realizarea unui use case.
 Decizia este luată funcţie de o anumită intrare recepţionată şi nu depinde de stare.
 Acţiunile iniţiate de un astfel de obiect depind numai de informaţiile conţinute
în mesajul de intrare şi nu de ceea ce s-a întâmplat anterior în sistem.
 Un exemplu de utilizare ar fi aplicaţiile orientate pe servicii, în care obiectul
coordonator coordonează interacţiunea dintre un obiect de tip interacţiune utilizator
şi obiecte servicii.

Obiectele de control dependente de stare sunt obiecte a căror comportare
variază în fiecare din stările sale.
 Pentru descrierea unui astfel de obiect se utilizează diagrama de stare, realizată pe baza
modelului automatului cu stări finite.
 Un astfel de obiect

recepţionează evenimente care duc la tranziţia între stări

generează evenimente care controlează alte evenimente
Evenimentele generate depind nu numai de evenimentul de intrare ci şi de starea
curentă a obiectului.
 Într-un sistem de control există unul sau mai multe obiecte de control dependente de stare.

Pot exista mai multe obiecte de control dependente de stare de acelaşi tip.
 Fiecare obiect execută o instanţă a aceleaşi stări finite (descrisă cu diagrama de
stare), deşi fiecare obiect pare a fi într-o stare diferită.

Obiectele de control de tip timer sunt obiecte activate de un timer extern
(spre exemplu ceasul de timp real).
 Un astfel de obiect execută acţiuni sau activează alte obiecte
2.4.4. Clase şi obiecte de tip logica aplicaţiei
 Obiectele de tip logică de operare definesc logica aplicaţiei pentru
procesarea unei cereri a unui client

încapsulează regulile de operare independente unele de altele care se pot
separa în obiecte diferite;

separă regulile de operare de datele cu care operează
 regulile de operare se pot schimba independent de datele pe care le procesează.
 În general, un obiect de tip logica de operare accesează obiecte entitate
diferite pe parcursul execuţiei.
Dacă o regulă de operare nu se poate executa decât prin accesarea a
două sau mai multe obiecte entitate atunci ar trebui să existe un
obiect de tip regulă de operare separat.
Dacă o regulă de operare se execută prin accesarea unui singur obiect
entitate, atunci aceasta va fi modelată printr-o metodă a obiectului
entitate.
 Un obiect de tip regulă de operare trebuie să interacţioneze cu
obiectele entitate pentru a-şi executa regulile de operare ⇒
seamănă cu un obiect coordonator.

Diferenţa: spre deosebire de un obiect coordonator, a cărui principală
responsabilitate este supervizarea altor obiecte, un obiect de tip regulă de
operare are ca principală responsabilitate încapsularea şi execuţia regulilor de
operare.
 Obiectele de tip algoritm încapsulează algoritmi utilizaţi în
domeniul problemei.

Se utilizează
 în special în sistemele de timp real şi aplicaţiile inginereşti
 atunci când există algoritmi complecşi care se pot modifica independent
de alte obiecte.

Algoritmii simpli nu sunt încapsulaţi în obiecte de tip algoritm,
 sunt metode în obiectele entitate care operează cu datele încapsulate în
entitate.

În domeniul ingineresc algoritmii
 se rafinează iterativ,
 se rafinează independent de datele pe care le manipulează

îmbunătăţirea performanţelor

îmbunătăţirea acurateţei.

Un obiect de tip algoritm încapsulează datele pe care le foloseşte:
 date iniţiale
 rezultate intermediare
 valori de prag etc.

Un obiect de tip algoritm trebuie să interacţioneze în general cu alte
obiecte pentru a executa algoritmul.

Spre deosebire de obiectele coordonator, acesta are ca principală
responsabilitate încapsularea şi executarea unui algoritm
 Obiectele de tip serviciu

furnizează servicii pentru alte obiecte

se utilizează în general în arhitecturi şi aplicaţii orientate pe servicii

pot fi utilizate şi în arhitecturi de tip client/server sau arhitecturi
bazate pe componente:
 obiectele client solicită un serviciu obiectului serviciu şi primesc răspuns
de la acesta

nu iniţiază niciodată o cerere

răspunsul obiectului serviciu poate necesita asistenţa unor alte
obiecte de tip serviciu

poate încapsula date necesare satisfacerii cererii clientului

poate accesa obiecte entitate care încapsulează datele respective
 3. Modelarea dinamică a sistemelor software

3.1. Modelarea interacţiunilor dinamice

 Furnizează o vedere asupra sistemului în care se iau în considerare
mecanisme de control şi secvenţiere

în interiorul unui obiect (prin intermediul stărilor maşină finite)

între obiecte (prin analiza interacţiunilor dintre obiecte)
 Se bazează pe realizarea use case-urilor dezvoltate în faza analizei
şi specificării cerinţelor

Pentru fiecare use case se determină modul în care obiectele
participante în realizarea lui interacţionează dinamic

Pentru determinarea obiectelor participante la realizarea unui use case
se folosesc criteriile de structurare descrise în capitolul anterior.
 Interacţiunile se modelează prin diagrama de comunicare
(colaborare) sau diagrama de secvenţă
Diagrama de comunicare
 Diagramă de interacţiuni ce pune accentul pe organizarea
obiectelor ce participă la realizarea unui use case
 Într-o astfel de diagramă se arată explicit legăturile dintre obiecte
prin intermediul mesajelor
 ordinea în care intervin obiectele în realizarea use case-urilor se descrie
prin numere de secvenţă

Diagrama de secvenţă
 Pune accentul pe ordonarea în timp a mesajelor

numerotarea mesajelor se poate omite

Notaţia grafică este un tabel care are
 pe axa X obiecte
 pe axa Y mesaje ordonate crescător în timp

linia vieţii - linie punctată verticală

perioada în care obiectul are controlul execuţiei - reprezentată printr-un dreptunghi
subţire pe linia vieţii;
 în această perioadă obiectul efectuează o acţiune, direct sau prin intermediul
procedurilor subordonate.

În faza de analiză accentul este pus pe capturarea informaţiilor pasate între

obiecte şi nu pe operaţiile invocate
⇒ nu se ia nici o decizie referitoare la faptul că un obiect este activ sau nu
3.1.1. Modelarea interacţiunilor independente de stare
1. Realizarea modelului use case
 Se consideră fiecare interacţiune între actorii primari şi sistem.
2. Determinarea obiectelor necesare realizării use case-urilor

Se aplică criteriile stabilite în secţiunea dedicată structurării obiectelor
 Determinarea obiectelor limită.

Se vor considera actorii care participă într-un use case;

Se determină obiectele externe prin care actorii comunică cu sistemul şi obiectele
software care recepţionează intrările de la actori.

Se consideră intrările de la obiectele externe către sistem.
 Pentru fiecare eveniment extern de intrare se vor considera obiectele
software necesare pentru procesarea evenimentelor.
 Un obiect limită software (obiect de intrare sau obiect interacţiune utilizator)
este necesar pentru recepţionarea intrărilor externe.
 După recepţionare, obiectul limită procesează şi trimite un mesaj către un
obiect intern.
 Determinarea obiectelor software interne.

Se consideră secvenţa principală a unui use case.

Se determină obiectele software ce participă la realizarea acestuia (obiecte tip
entitate sau obiecte tip control).
3. Determinarea secvenţei de mesaje
 Pentru fiecare intrare de la obiectele externe se vor considera
comunicările între obiectele limită ce recepţionează evenimentul şi
obiectele de tip control sau entitate ce îl procesează.
 Se realizează diagrama de secvenţă sau de comunicare care arată
obiectele participante la realizarea use case-ului şi secvenţa de mesaje
dintre acestea:
Intrare externă de la actor (obiect extern);
Secvenţă de mesaje interne;
Mesaj transmis către actor (obiect extern).

4. Determinarea secvenţelor alternative

 Se vor considera diferite alternative din diagrama use case.
 Se determină obiectele participante şi mesajele dintre acestea.
3.1.2. Modelarea interacţiunilor dinamice dependente de
stare

1. Determinarea obiectelor de tip limită.

Se vor considera obiectele ce recepţionează intrări trimise de
obiectele externe.
2. Determinarea obiectelor de tip control dependente de stare.

Există cel puţin un obiect de control care execută o diagramă de
stare.
3. Determinare altor obiecte software: obiecte ce interacţionează cu
obiectele de control sau cu cele de tip limită.
4. Determinarea interacţiunilor între obiecte ce realizează secvenţele
principale ale use case-urilor.

Se realizează în conjuncţie cu etapa 5 deoarece interacţiunea dintre
obiectele de control dependente de stare şi diagramele de stare pe
care le execută trebuie determinate în detaliu.
5. Determinarea execuţiei diagramei de stare.
6. Considerarea scenariilor alternative.
 Dacă un mesaj ajunge la un obiect de control dintr-o
diagramă de comunicare, evenimentul care este parte
a mesajului determină o tranziţie într-o diagramă de
stare.

 O acţiune dintr-o diagramă de stare este rezultatul

unei tranziţii şi corespunde unui mesaj de ieşire
descris în diagrama de comunicare.
 3.2. Diagrama de stări

Este folosită pentru a modela comportamentul unui obiect.

Specifică o secvenţă de stări prin care trece un obiect de-a lungul vieţii sale ca
răspuns la evenimente împreună cu răspunsul la aceste evenimente.

Realizarea diagramelor de stare pornind de la use case-uri

1. Iniţial, diagrama se realizează urmărind secvenţa de evenimente din secvenţa

principală.

Stările reprezintă consecinţe ale acţiunilor întreprinse de actor, direct sau indirect.
2. Pentru completarea diagramei se determină toate evenimentele externe posibile
care pot fi intrări în diagramă.

Pentru aceasta se iau în considerare şi căile alternative descrise în use case.
3. În unele aplicaţii, o diagramă de stare poate participa în mai multe use case-uri.

În această situaţie, vor exista diagrame parţiale pentru fiecare use case.

Aceste diagrame parţiale trebuie integrate în diagrama completă.
 Pentru integrare trebuie identificate stările comune.
4. Ultimul pas este organizarea ierarhică a diagramelor de stare.

Prima abordare este de tip top-down, adică se determină stările de nivel înalt care
apoi se descompun.

Într-o altă abordare se dezvoltă o porţiune a diagramei şi apoi se încearcă
agregarea unor stări într-o stare compusă.