1)Digramele fluxurilor de date:

Simbol

Semnificaţie
Notaţia Yourdon- Notaţia Gane-Sarson
DeMarco

- se foloseşte pentru a reprezenta

grafic un proces care transformă un
flux de intrare într-un flux de ieşire.
De asemenea, se foloseşte pentru a
prezenta grafic sistemul sau
subsistemul. Etichetele din
interiorul simbolului sunt diferite
pentru cazul când este prezentat
sistemul (exemplu: sistem de
evidenţă a comenzilor) sau
procesul (exemplu: recepţionarea
şi înregistrarea comenzilor).

- se foloseşte pentru a prezenta

grafic un loc de stocare a datelor
(datele se păstrează până la o
utilizare ulterioară). Eticheta din
interiorul simbolului trebuie să
reflecte cât mai exact conţinutul
datelor care se pătrează în acest
loc de stocare.

- flux de date – reflectă transferul

datelor/informaţiilor între diverse
entităţi. Eticheta de pe fluxul de
date poate să reflecte o denumire a
unui flux logic de date, dar şi un
flux fizic de date.

- simbol utilizat pentru a prezenta

entitatea externă, care reprezintă
obiecte amplasate înafara hotarelor
sistemului. Entitatea externă
reprezintă sursa datelor sau
destinaţia informaţiilor sistemului.
Drept etichetă se va folosi un
substantiv la singular, chiar dacă
acele obiecte-externe sunt mai
multe (exemplu: casier, chiar dacă
7 casieri inregistr. vanzarile.
 1.Exemplu de diagramă de context

Secţia achiziţii
publice

Informaţii referitoare la
Informaţii referitoare
iepuizarea de stocuri si
la noi intrări
necesitatea de noi procurari

Foaia de drum semnată şi

cu înscrierile necesare
Sistem de Factura de iesire
evidenţă SISTEM DE
EVIDENŢĂ A Donator
contabila Factura de intrare inregistrata;
VACCINURILOR Foaia de drum cu factura de
Rapoarte statistice şi informaţii
(expirări, deteriorări vaccinuri) intrare înregistrată

Factura de ieşire, Lista vaccinurilor

înregistartă solicitate

Instituţie
medicală

2.Exemplu de DFD detaliată a procesului de evidenţă a vânzărilor de medicamente

Manager aprovizionare Date medicamente intrate

Date stocuri disponibile Cerere date 4. Predarea

Date necesare medicamentelor din
inregistrarii noilor stocuri depozit
3. Formarea stocurilor de produse Date stocuri
medicamente

Loc de stocare
Cerere situatie stocuri
comun a datelor Detalii aprovizionare cu medicamente
referitoare la Date medicamente
5. Date pentru raport
medicamente
Raportare
situatie Date vanzari
vanzari 1. Inregistrarea
Date vanzare comenzii de
Informatii Cerere medicamente
situatie conturi raport Detalii pentru informare

Cerere date

Date Date pentru

Contabilitate medicamente crearea vanzarii

2. Informarea Date comanda

Farmacist
clientului Informatii
medicament
 2)Digramea cazurilor de utilizare

O diagrama a cazurilor de utilizare (use case diagram) prezinta o colectie de cazuri de

utilizare si actori care:

 ofera o descriere generala a modului in care va fi utilizat sistemul

 furnizeaza o privire de ansamblu a functionalitatilor ce se doresc a fi oferite de sistem

 arata cum interactioneaza sistemului cu unul sau mai multi actori

 asigura faptul ca sistemul va produce ceea ce s-a dorit.

Un actor este un stereotip al unei clase. Actorii sunt reprezentati de utilizatori sau entitati care
pot interactiona cu sistemul. Ei nu fac parte din sistem si definesc multimi de roluri in comunicarea
cu acesta.
Un actor se reprezinta sub forma unui ”omulet” sub care se trece numele acestuia (vezi Figura 1).

Figure 1: Reprezentarea unui Actor in UML

Identificarea actorilor se face raspunzand la urmatoarele intrebari:

• Cine doreste sau este interesat de informatiile aflate in sistem?

• Cine modifica date?

• Cine interactioneaza cu sistemul?

Intre actori poate exista relatia de generalizare. Daca un actor mosteneste un alt actor, atunci el
poate sa comunice cu aceleasi cazuri de utilizare ale sistemului ca si parintele sau. Notatia UML este
o sageata cu linie continua, avand la capat un triunghi gol, care indica spre actorul parinte(vezi
Figura 2).
 Un caz de utilizare reprezinta o colectie de scenarii posibile, referitoare la comunicarea intre sistem
si actorii externi, caracterizate de anumite scopuri. Aceste scenarii sunt definite ca secvente de pasi
carora le pot corespunde cazuri de utilizare de nivel inferior. Cazurile de utilizare arata ce trebuie sa
faca sistemul si nu cum trebuie să facă.

Un caz de utilizare se reprezinta sub forma unui oval in care se trece numele acestuia

Figure 3: Reprezentarea unui caz de utilizare in notatia UML

Intre cazurile de utilizare pot exista urmatoarele relatii:

• incluziune: un caz de utilizare include comportamentul altui caz de utilizare

Figure 4: Relatia de incluziune intre cazurile de utilizare

• extindere: arata ca un caz de utilizare este inserat intr-un altul, dar numai in anumite conditii

Figure 5: Relatia de extindere intre cazurile de utilizare

• generalizare: un caz de utilizare mosteneste comportamentul altui caz si il rafineaza

Figure 6: Relatia de generalizare intre cazurile de utilizare

O asociere reprezinta o conexiune semantica intre cazurile de utilizare si actori.

Asocierile se reprezinta printr-o linie plasata intre entitatile de asociate (vezi Figura 7).
Exemplu:
Sa se realizeze diagrama cazurilor de utilizare pentru un produs software ce urmeaza de-serveasca o
casa de marcat din cadrul unui supermagazin. Consideram urmatorul scenariu:

1. Clientul solicita produsul.

2. Vanzatorul realizeaza facturarea acestuia. Pentru acesta:
a. se scaneaza codul de bare

b. se cauta in baza de date codul produsului

c. daca produsul este gasit se adauga la factura

d. daca produsul nu este gasit este respins

Din enuntul anterior se identifica urmatorii actori:
• Client
• Vanzator

Cazurile de utilizare corespunzatoare functionalitatii descrise sunt urmatoarele:

• Solicitarea produsului

• Facturarea

• Citirea codului de bare

• Cautarea in baza de date

• Adaugarea produsului la factura

• Respingerea produsulu
Diagrama Use Case (cazurilor de utilizare)
 1. Construiţi diagrama Gantt şi PERT pentru următoarele activităţi. Alocaţi resursele necesare îndeplinirii
activităţilor:
Denumirea activităţii Data de început Data de sfârşit

1. Elaborarea planului proiectului 17.02.2014 20.02.2014

2. Prezentarea planului - 21.02.2014

3. Definirea cerinţelor

3.1. Formularea iniţială a cerinţelor 24.02.2014 28.02.2014

3.2. Specificarea (inclusiv grafic) a cerinţelor 03.03.2014 04.03.2014

3.3. Adaptarea planului dezvoltării 03.03.2014 04.03.2014

3.3. Elaborarea sarcinii tehnice 05.03.2014 07.03.2014

3.4. Prezentarea sarcinii tehnice - 10.03.2014

4. Proiectarea SI

4.1. Planificarea instruirii utilizatorilor 11.03.2014 12.03.2014

4.2. Proiectarea logicii 13.03.2014 18.03.2014

4.3. Proiectarea BD 13.03.2014 17.03.2014

4.4. Proiectarea arhitecturii fizice a SI 18.03.2014 19.03.2014

4.4. Proiectarea interfeţelor de dialog 19.03.2014 21.03.2014

4.5. Prezentarea proiectului tehnic - 24.03.2014

5. Realizarea SI

5.1. Programarea front-end-ului 25.03.2014 11.04.2014

5.2. Programarea back-end-ului 25.04.2014 15.04.2014

5.3. Elaborarea planului de testare a soft-ului 16.04.2014 17.04.2014

5.4. Procurarea şi instalarea componentelor hardware a SI 16.04.2014 18.04.2014

5.5. Elaborarea ghidului utilizatorului 21.04.2014 23.04.2014

5.6. Elaborarea documentaţiei de instalare şi operare 21.04.2014 23.04.2014

6. Integrarea şi testarea
 6.1. Testarea şi rapoarte ale testării 24.04.2014 25.04.2014

6.2. Planificarea finală a instruirii utilizatorilor 29.04.2014 30.04.2014

6.3. Elaborarea listei de acceptări ale verificărilor 29.04.2014 30.04.2014

6.4. Elaborarea versiunii finale a ghidului utilizatorului 01.05.2014 02.05.2014

6.5. Instalarea softului şi instruirea administratorilor 05.05.2014 06.05.2014

6.6. Predarea produsului - 07.05.2014

7. Elaborarea planului de întreţinere. Întreţinerea şi exploatarea 08.05.2014 09.05.2014

SI.