BONUS 3

3. În BPMN fluxurile de secventa pot traversa:

R=Noduri

1. Model View Controller (MVC) este

R=Un model de arhitectura software

4. Diagrama UML de desfasurare descrie:

R=Elemente hardware ale sistemului

5. În proiectarea bazelor de date se pleacă de la:

R=MODELUL CLASELOR DOMENIULUI

6. Care dintre urmatoarele activitati nu sunt include in etapa de proiectare a bazei de date:

R=Proiectarea codurilor folosite in baza de date

7. În diagrama BPMN de mai jos se reprezinta:B SAU C

R=un singur/mai multi participanti

8. Evenimentele de tip timp in limbajul BPMN sunt intotdeauna de tipul

R=De inceput
9. In urmatoarea diagrama BPMN sunt reprezentate:

R=O poarta bazata pe evenimente si trei evenimente intermediare

10. Diagrama UML de componente este formata din:

R=Componente, interfete
 BONUS 1

1. Cerința ”Un produs trebuie livrat în intervalul orar specificat de cumpărator” este un
exemplu de cerinta:
RĂSPUNS: Funcțională
2. Care dintre diagramele de mai jos modelează faptul că un director poate conține o colecție
de fișiere?
RĂSPUNS: B)

3. Identificati enuntul fals referitor la limbajele formale:

RĂSPUNS: includ limbaje precum UML sau BPMN

4. Care dintre enunțurile de mai jos reprezintă un aspect practic referitor la identificarea
cerințelor?
RĂSPUNS: Este necesară implicarea activă a beneficiarului
5. Etapa de anliză a unui sistem informatic are următoarele caracteristici:

RĂSPUNS:A) 1+2+5
6. Identificati enunțul fals referitor la relația de agregare:

RĂSPUNS: Agregarea compusă este un tip slab de agregare

7. Care dintre variantele de diagrame de cazuri de utilizare modelează corect următorul enunț?
”Pentru ca un produs finit să fie lansat pe piață, este necesar să se evalueze caracteristicile
de calitate ale acestuia”.
RĂSPUNS: B
8. Asocierea modelată ca o clasă este folosită atunci cand:
RĂSPUNS: Asocierea dintre clase are propriile atribute și operații

9. Relatiile dintre cazurile de utilizare pot fi de tipul:

RĂSPUNS: C)EXTINDERE, INCLUDERE, GENERALIZARE

10. Ce este gresit în diagrama cazurilor de utilizare din figură?

RĂSPUNS: Relatia dintre actori

BONUS 2
1. Diagrama de secvențe:
R: subliniază ordinea mesajelor schimbate între obiecte în funcție de timp

2. O tranziție între stări în diagrama cu mașini cu stări poate să conțină:

1.declanșator
2.conditie
3.obiect
4.efect

R: 1+2+4

3. În diagrama de activitate, un jeton:

R: are rolul de a descrie execuția

4. În limbajul UML o acțiune din cadrul diagramei de activitate

R:Nu mai poate fi descompusa

5. Următoarele diagrame nu folosesc pentru reprezentarea lor noduri decizionale

1.diagramele de clase
2.diagramele de activitati
3.diagramele de stare
4.diagramele de cazuri de utilizare

R: 1+4

6. Care dintre afirmatiile referitoare la urmatoarea diagrama sunt corecte?

 R=1+5

7. În limbajul BPMN o poartă:

R: poate fi inclusivă sau exclusivă

8. În diagrama UML de activitate din figură, acțiunea E:

R: se realizează atunci cand are loc un eveniment

9. Care dintre următoarele afirmați despre fragmentele combinate din diagramele de secvență
UML este adevărată:
R: Permit să introducem logică procedural în diagram de secvență
 10. Este specific unei stări într-o diagrama UML:
R: poate include acțiuni speciale

SEMINAR 2

1. Care dintre urmatoarele variante reprezinta surse pentru identificarea cerintelor?

BENEFICIARUL
ARTEFACTELE

2. Este necesara implicarea activa a beneficiarului deoarece

CERINTELE SE SCHIMBA
PUTEM OBTINE FEEDBACK FRECVENT
SE POT ELIMINA EMBIGUITATI
SE POT REZOLVA ASPECTE NEINTELESE

3. Regulile dintr-o tabela de decizie contin:

Conditii si actiuni

4. Ce structura de control din programare implementeaza o tabela de decizie?

IF-THEN

SEMINAR 3

1. Intre cazurile de utilizare pot exista relatii de tipul:

Includere

2. In urmatoarea figura multiplicitatile apar:

 La capatul corespunzator cazului de utilizare si la capatul corespunzator actorului

3. Se recomanda ca numele cazurilor de utilizare sa inceapa cu un:

VERB

4. Relatia de extindere intre cazuri de utilizare indica un comportament:

Optional

APROFUNDAM 3

Identificati exemplul gresit din figurile de mai jos

RASPUNS: VARIANTA A
 APROFUNDAM 4

Ce tip de relație este potrivită pentru cazurile de

utilizare din figură?

Variante de răspuns:
A) Includere
B) Asociere
C) Generalizare?
D) Extindere

SEMINAR 4
 1. Folosim multiplicitatea atributelor clasei atunci cand
dorim sa:

B. Definim mai mult de o valoare pentru un atribut

2. Indicati enuntul fals

A: Asocierea este un tip de agregare

3. Generalizarea descrie o relatie de genul:

RASPUNS: ESTE UN TIP DE

4. Asocierea unara (reflexiva) arata o relatie intre:

RASPUNS: Obiectele aceleiasi clase

APROFUNDAM 1

Cum modelati urmatoarea situatie intr-o diagrama de clase UML:

O comanda este plasata cu ajutorul unui chelner, un chelner se

ocupa de mai multe comenzi.

A.1+2
A.1+2

APROFUNDAM 2

D) 3+4
Pornind de la diagrama din imagine, care dintre urmatoarele
afirmatii este adevarata?

1. Un OBIECT al clasei A poate avea asociat un obiect al clasei B

2. Daca o instanta a lui B este stearsa, atunci sunt sterse si toate
instantele lui A
3. Rombul de langa A poarta numele de compunere
4. Un obiect al lui B este inclus intr-un sigur obiect al lui A

D) 3+4

APROFUNDAM 3

O relatie de generalizare intre o subclasa si o superclasa are

urmatoarele propozitii:

1. subclasa mosteneste proprietatile superclasei

2. subclasa poate mosteni de la o singura superclasa
 3. subclasa nu poate avea mai multe atribute si operatii decat
supercalsa
4. superclasa nu poate sa fie abstracta

A)1

APROFUNDAM 4
-Numele clasei: Pacient

-Stereotipul: entity

-Atributele: CodPacient, Nume, Adresa, DataNastere

-Valoarea initiala: 0, semnul –

-Vizibilitatea atributelor: SEMNUL - din fata fiecarui

atribut=PRIVATE

-Tipul atributelor: INT, char, char, Date

-Operatiile: METODE

-Semnatura operatiilor: +getNume(), +getCodPacient(),

+schimbaAdresa()

-Vizibilitatea operatiilor: + (PUBLIC)

-Valoarea returnata: BOOLEAN, BOOLEAN, BOOLEAN

SEMINAR 5

1.Pentru diagrama de activitate din figură, care dintre

următoarele secvențe de acțiuni este posibilă în timpul
execuției?
1.A → B → C → D
2.A → B → D → C
3.A → C → B → D
4.A → B → D
5.A → C

Variante(răspunsunic):
a)1+2+3+4
b)1+2+4
c)1+2+3
d)4+5

2.

Aprofundăm-2
Pentru diagrama de activitate din figură, care dintre
următoarele secvențe de acțiuni este posibilă în timpul
execuției?
1.A → C
2.A → B → D
3.A → B → D → C
4.A → B → C
Variante
1.A → C
2.A → B → D
3.A → B → D → C
4.A → B → C

Variante (răspunsunic):
a)1+3
b)1+2
c)3
d)4

3.
3. Nodul de bifurcație (Fork) într-o diagramă de
activitateare ca și caracteristici (răspuns multiplu):
a)Este folosit pentru modelarea fluxurilor paralele
b)Este o alternativă a nodului decisional - FALS
c)Transmite jetoane către toate arcele de ieșire
d)Poate fi folosit doar în combinație cu nodul de
sincronizare (Join) - posibil
4.
Identificați care dintre următoarele afirmații despre
partițiile dintr-o diagramă de activitate UML sunt
adevărate (răspuns multiplu):
1.Partițiile grupează nodurile și arcele unei activități - A
2.Partițiile ajută la clarificarea modelului – A
3.Partițiile pot fi utilizate pentru a organiza
responsabilitățile actorilor pentru anumite acțiuni. - A
4.Partițiile nu trebuie să aibă o adâncime ierarhică mai
mare decât unu - F
5.
Identificați care dintre următoarele noduri sunt
elemente ale unei diagrame de activitate în limbajului
UML (răspuns multiplu):
a)Nod final al fluxului
b)Nod de sincronizare
c)Nod de tăiere
d)Nod de comunicare
e)Nod de bifurcație
f)Nod decizional
g)Nod de distribuție

SEMINAR 10
1. În exemplul din figură subprocesul
Achiziție:

Variante:
a)este întrerupt de evenimentul Livrare
întârziată
b)nu este întrerupt de evenimentul Livrare
întârziată
c)nu este întrerupt de evenimentul Indisponibil
d)nu poate fi interrupt

2. Porțile inclusive în limbajul BPMN:

1.pot avea mai multe fluxuri de ieșire
2.pot avea un singur flux de ieșire
3.nu evaluează condiții
4.evaluează mai multe condiții
 Variante:
a)1+3
b)1+4
c)2+3
d)2+4

3. Evenimentele în limbajul BPMN

desemnează:
a)ceva ce se realizează în cadrul unui
process
b)ceva ce se întâmplă în timpul unui
process
c)ceva ce controlează divergenţasau
convergenţaunor fluxuri de activităţid)ceva
ce descrie ordinea elementelor din flux

EXAMEN - 2 IUNIE 2020

1. Care dintre următoarele afirmații despre diagramele mașinii de stare sunt

adevărate?

RĂSPUNS: activitățile pot fi executate atat în cadrul stărilor cat și în timpul

tranzițiilor

2. Care dintre următoarele afirmații despre fragmentele combinate din

diagramele de secvență UML sunt adevărate?
1)un fragment combinat este format dintr-unul sau mai multe subfragmente

2.)unele fragmente combinate pot controla fluxul de acțiune

3)un fragment combinat este o instanță a unei clase din cadrul sistemului

4.)permit să introducem logică procedurală în diagrama de secvență

RĂSPUNS: 1+2+4

3. Pentru diagrama de activitate din figură, care dintre următoarele secvențe de

acțiuni este posibilă în timpul execuției?

1) A-C

2)A-B-D

3)A-B-D-C

4)A-B-C

RĂSPUNS: 1+2

4. Termenul de arhitectură tehnică se referă la:

RĂSPUNS: toate tehnologiile necesare pentru a susține aplicația software

5. Care dintre următoarele declarații referitoare la diagrama de activitate este

adevărată?
1)o acțiune este formată din mai multe activități

2)acțiunile sunt atomice

3)acțiunile nu pot fi întrerupte

4)acțiunile pot manipula obiecte și valorile acestora

RĂSPUNS: 2+4

6. Reprezintă dezavantaje ale metodologiilor bazate pe dezvoltarea agilă:

1)nu sunt potrivite pentru a gestiona dependențe complexe

2)oferă flexibilitate

3)lipsa regulilor poate duce la apariția unui mediu de lucru haotic

4)depind foarte mult de interacțiunea cu beneficiarul

RĂSPUNS: 1+3+4

1. Prin intrari informationale se intelege

=totalitatea datelor primare necesare obtinerii

7. În exemplul din figură subprocesul Achiziție:

RĂSPUNS: nu este întrerupt de evenimentul Livrare întarziată

8. Pornind de la diagrama din imagine, care dintre următoarele afirmații este

adevărată?

1)Un obiect al clasei A poate avea asociat un obiect al clasei B

2)Dacă o instanță a lui B este ștearsă, atunci sunt șterse și toate instanțele lui A

3)Rombul de langă A poartă numele de compunere

4)Un obiect al lui B este inclus într-un singur obiect al lui A

RĂSPUNS: 3+4

9. Diagrama de sevcențe:

RĂSPUNS: subliniază ordinea mesajelor schimbate între obiecte în funcție de

timp

10. Pentru diagrama de secvență din figură, care dintre următoarele afirmații
este adevărată

RĂSPUNS: Secvența de mesaje ulterioare fragmentului break se va executa

doar dacă parola a fost introdusă greșit de cel puțin 3 ori

11.Care dintre următoarele cazuri de utilizare este un caz de utilizare corect dacă
vrem să realizăm o diagramă de cazuri de utilizare pentru un magazin online de
cărți?

1)Caută o carte

2)Comandă o carte
3)Nu comandă o carte

4)Anulează o comandă

5)Login

6)Introduce nume carte

RĂSPUNS: 1+2+4

12. Care dintre următoarele afirmații referitoare la maparea obiectelor în tabele

ale unui SGBDR este falsă?

RĂSPUNS: atributele multivaloare ale unui obiect devin coloane ale tabelei
echivalente

13. Specificațiile descriptive ale unui sistem informatic:

1)pot fi negociate sau schimbate

2)nu pot fi negociate sau schimbate

3)sunt generate de legi ale naturii

4)sunt generate de constrangeri

RĂSPUNS: 2+3+4

14. O diagramă de componente prezintă:

RĂSPUNS: dependențele existene între diverse componente software ce

compun un sistem informatic

15.Pentru diagrama de secvență din figură, care ordine a mesajelor este posibilă?
RĂSPUNS: a-c-b-d

16. Care dintre următoarele afirmații referitoare la proiectarea interfețelor este

adevărată?

1)harți cu structura ecranului sunt utilizate pentru a descrie fluxul aplicației

urmand principalele moduri de utilizare

2)modelarea unei interfețe se face cu ajutorul diagramei specifice UML

3)așteptările actorilor cu privire la interfețe sunt aflate prin completarea de

chestionare

4)proiectarea interfețelor nu trebuie să țină cont de obiectivele actorului în

interacțiunea cu sistemul

RĂSPUNS: 1+3

17. Care dintre următoarele enunțuri referitoare la diagrama din figură sunt
adevărate?
1) A și B execută Y împreună

2) A și B execută Y separat

3) Z moștenește de la Y și este un Y specializat

4) A sau B pot executa Z

RĂSPUNS: 2+3+4

18. Care dintre următoarele afirmații despre diagramele mașini de stare sunt
adevărate?

RĂSPUNS: activitățile pot fi executate atat în cadrul stărilor cat și în timpul

tranzițiilor

19. Care dintre următoarele afirmații despre fragmentele combinate din

diagramele de secvență UML sunt adevărate?

1) un fragment combinat este format dintr-unul sau mai multe subfragmente

2) unele fragmente combinate pot controla fluxul de acțiune

3)un fragment combinat este o instanță a unei clase din cadrul sistemului

4)permit să introducem logică procedurală în diagrama de secvență

RĂSPUNS: 1+2+4

20. Pentru diagrama de activitate din figură, care dintre următoarele secvențe de
acțiuni este posibilă în timpul execuției?

1) A-B-C

2)A-C-B

3)A-B

4)A-C

RĂSPUNS: 3+4

21. În porțile bazate pe evenimente din limbajul BPMN:

1)nu se iau decizii

2)decizia este luată de către un alt participant

3)deciziile se bazează pe producerea unor evenimente

4)deciziile se bazează pe date

RĂSPUNS: 2+3
22. Pentru diagrama de activitate din figură, care dintre următoarele secvențe de
acțiuni este posibilă în timpul execuției?

1) A-B-C-D

2)A-B-D-C

3)A-C-B-D

4)A-B-D

5)A-C

RĂSPUNS: 1+2+3

23. O diagramă de clasă descrie:

RĂSPUNS: Perspectiva statică asupra unui sistem

24. Cum modelați următoarea situație într-o diagramă UML de cazuri de

utilizare:

Un mecanic efectuează verificarea unei mașini. În timpul acestei verificări,

poate fi necesară schimbarea unei piese

Alegeți o opțiune:
25. Evenimentele în limbajul BPMN desemnează:

RĂSPUNS: ceva ce se întamplă în timpul unui proces

26. Vi se oferă următoarea diagramă de stare. Starea B este definitiv părăsită

dacă:

1)evenimentul e1 are loc

2)cele 2 regiuni ortogonale au ajuns la stările finale

3)evenimentul e2 are loc

4)una dintre cele 2 stări finale este atinsă

RĂSPUNS: 1+2

27. O relație de generalizare între o subclasă și superclasă are următoarele

proprietăți:

1)subclasa moștenește proprietățile superclasei

2)subclasa poate moșteni de la o singură superclasă

3)subclasa nu poate avea mai multe atribute și operații decat superclasa

4)superclasa nu poate să fie abstractă

RĂSPUNS: 1

28. Cum modelați următoarea situație într-o diagramă de clase UML?

O comandă este plasată cu ajutorul unui chelner, un chelner se ocupă de mai

multe comenzi
RĂSPUNS: 1+2

29. Între cazurile de utilizare pot exista relații de tipul:

1)Asociere

2)Includere

3)Specializare

4)Extindere

5)Generalizare

RĂSPUNS: 2+4+5

30. Cerințele non-funcționale sunt legate de:

RĂSPUNS: operaționalitatea sistemului

31. Care dintre acestea sunt tipuri de noduri utilizate în diagrama de

desfășurare?

RĂSPUNS: dispozitive și medii de execuție

32. Care dintre următoarele afirmații despre diagramele mașinii de stare sunt
adevărate?

1)O condiție este evaluată numai atunci cand are loc evenimentul corespunzător
2)Starea inițială are exact un flux de ieșire și orice număr de fluxuri de intrare

3)Cand are loc un eveniment care declanșează trecerea la o altă serie, activitatea
do este abandonată

4)Evenimentele declanșează tranziții

5)Activitățile declanșează tranzițiile

RĂSPUNS: 1+3+4

Alți ani

33. Metodologiile bazate pe dezvoltarea agilă au ca și caracteristici:

A) livrarea de software funcțional se face frecvent

B)depind foarte mult de interacțiunea cu beneficiarul

C) promovează dezvoltarea durabilă

D) sunt potrivite pentru mediile care nu se schimbă

RĂSPUNS: A+B+C

34. În arhitectura orientată pe servicii (SOA) furnizorii de servicii au rolul de a:

RĂSPUNS: implementa funcționalitatea

35. Ciclul de dezvoltare a unui sistem informatic cuprinde:

RĂSPUNS: Etapa de analiză

36.Determinarea intrărilor sistemului pornind de la ieșirile acestuia se face

utilizand tehnica:

RĂSPUNS: concordanței ieșiri-intrări

37. Nu reprezintă o caracteristică a diagramelor de desfășurare în limbajul UML

RĂSPUNS: un nod reprezintă o aplicație informatică

38. Limbajele formale sunt cele pentru care pot fi verificabile

RĂSPUNS: regulile de sintaxă și de semantică

39. În limbajul BPMN fluxu de secvență:

RĂSPUNS: descrie ordinea elementelor din flux în modelele de proces

40. Facilitatea de Reverse Enigineering asigură păstrarea concordanței între:

RĂSPUNS: modificările care au loc în cod și modelele dezvoltate în etapa de

proiectare

41. Prin mentenanța perfectivă se urmărește să se adauge sistemului:

RĂSPUNS: trăsături dorite, dar nu neaparat necesare

42. Codurile se pot grupa după:

A. natura caracterelor

B. lungimea codului

C. semnificația codului

D. structura codului

RĂSPUNS: A+B+C+D

43. Într-o diagramă de componente nu vom intalni următoarele tipuri de relații:

RĂSPUNS: extindere și generalizare

44. Acele limbaje pentru modelarea informațională care au reguli stricte iar
sintaxa și semantica sunt definite matematic se numesc:

RĂSPUNS: Limbaje formale

45. Arhitectura orientată pe servicii (SOA)

RĂSPUNS: divide o aplicație într-un coordonator de servicu, care reprezintă

funcționalitatea la utilizator și furnizorii de servicii, care implementează
funcționalitatea

46. În limbajul BPMN porțile paralele

RĂSPUNS: nu verifică nicio condiție care să ducă la declanșarea ieșirilor

47. În abordarea orientată obiect, modelarea aspectelor statice ale unui sistem se
realizează prin:

RĂSPUNS: diagrama claselor

48. Printre componentele unui sistem informatic se numără

RĂSPUNS: b)Comunicațiile, c)Software-ul, d)Utilizatorii

49. O metodologie de realizare a unui sistem informatic trebuie să cuprindă

RĂSPUNS: a)detalii privind tehnologiile de implementare a sistemului

informatic, b)limbajele de programare utilizate, c)modalitatea de derulare a
ciclului, d)instrumente specifice scrierii de cod sursă

50. Proiectarea unui sistem informatic implică

a)proiectarea codurilor

b)proietarea mediului

c)proiectarea cerințelor

51. Relațiile de asociere între clase pot

RĂSPUNDE: include multiplicități

52. Cerința Sistemul nu trebuie să mai funcționeze în caz de incendiu este un

exemplu de cerință de

RĂSPUNS: siguranță

53. În limbajul BPMN un eveniment are următoarele caracteristici:

RĂSPUNS: d. afectează fluxul unui model

54. Identificaţi enunţul care este caracteristic sistemelor informatice pentru

managementul tactic

RĂSPUNS: baza de cunostine si modele

55. Ciclul de dezvoltare al unui sistem informatic cuprinde

RĂSPUNS: intervalul de timp de la luarea deciziei de realizare a unui sistem

până la introducerea sistemului în exploatare

56. Într-un nod decizional din diagrama de activitate:

RĂSPUNS: a. fluxurile de ieşire au condiţii mutual exclusive

57. Distribuirea datelor, in arhitecturile distribuite, poate fi

RĂSPUNS: distribuire prin replicare;b) distribuire prin fragmentare;

58. O metodologie de realizare a unui sistem informatic trebuie să cuprindă:

RĂSPUNS: a) etapele şi procesele de realizare; c) tehnicile, procedurile,

instrumentele, normele şi standardele utilizate; d) regulile de formalizare a
componentelor sistemului informatic

59. La proiectarea situaţiilor cu rezultate finale, macheta

RĂSPUNS: este reprezentarea de detaliu a unei situaţii de ieşire ;cuprinde

antetul, titlul, elemente fixe, capul de tabel şi data conţine specificaţii care
servesc utilizatorului

60. Sistemul informatic este:

RĂSPUNS: a) un ansamblu de componente intercorelate funcţional, în scopul

automatizării obţinerii informaţiilor necesare managementului în procesul de
fundamentare şi elaborare a deciziilor; c) un ansamblu de modele matematice
pentru optimizarea proceselor;

61. Metodologiile Extreme Programming (XP) și SCRUM se încadrează în

categoria metodologiilor

RĂSPUNS: bazate pe dezvoltare Agile

62. Cerinţele impuse codurilor sunt :

RĂSPUNS: a) unicitate. conciziune, semnificative;

b) operationalite, elasticitate, claritate;

SAU

a) unicitate. conciziune, semnificative;

b) operationalite, elasticitate, claritate;

c) unicitate, conciziune, portabilitate;

d) operationalitate, elasticitate, comunicare

A+B+C

63. La proiectarea situaţiilor cu rezultate finale, macheta :

a) este reprezentarea de detaliu a unei situaţii de ieşire

b) cuprinde antetul, titlul, elemente fixe, capul de tabel şi date elementare

c) conţine specificaţii care servesc utilizatorului

d) conţine specificaţii care servesc administratorului de retea

64. Instrumentele de tip CASE nu pot să asigure următoarele facilităţi :

RĂSPUNS: implementarea directa a SI

65. Reprezintă caracteristici ale diagramei de cazuri de utilizare :

RĂSPUNS: c. descrie fluxuri de activităţi

66. Sistemul informatic are următoarele caracteristici :

RĂSPUNS: este inclus în cadrul sistemului informaţional-decizional,

67. Cerintele non -functionale pot fi:

a) de calitatea serviciilor;

b) de calitate;
c) constangeri arhitectoriale;

d) de subordonare;

se ocupă de culegerea, stocarea şi prelucrarea automată a datelor,

68. Diagramele de stare din UML :

RĂSPUNS: c. modelează starea dinamică a unui obiect specific

69. În abordarea orientată obiect, modelarea aspectelor statice ale unui sistem se
realizează prin :

RĂSPUNS: diagrama de clase / diagrama de obiecte

70. Diagramele de activitate

RĂSPUNS: reprezintă comportamentul intern al unui caz de utilizare

71. Cerintele non -functionale pot fi:

a) de calitatea serviciilor;

b) de calitate;

c) constangeri arhitectoriale;

d) de subordonare;

RĂSPUNS: de calitatea serviciilor, de calitate, constrangeri

72. Distribuirea datelor, in arhitecturile distribuite, poate fi:

a) distribuire prin replicare;

b) distribuire prin fragmentare;

c) distribuire prin reconstructie;

d) distribuire prin complementare

RĂSPUNS: a) distribuire prin replicare; b) distribuire prin fragmentare;

73. În limbajul BPMN porţile paralele:

RĂSPUNS: d. nu verifică nicio condiţie care să ducă la declanşarea ieşirilor

74. Sistemul informatic are următoarele caracteristici :

RĂSPUNS: a) este inclus în cadrul sistemului informaţional-decizional

GRILE

SUBIECT NR2.- DAT LA ZI DE LA ALEX

1. Instrumentele CASE:
a. se bazeaza pe definirea specificatiilor pe suport de hartie
b. urmaresc cresterea complexitatii procesului de proiectare a unui SI
c. ofera suport proiectantului in realizarea unui produs informatic
d. sunt folosite pentru stocarea, prelucrarea si generarea informatiilor necesare pentru
gestiunea activitatilor si pentru fundamentarea deciziilor

2. Diagrama de secvente:
a. modeleaza aspecte statice ale sistemului
b. cuprinde stari, tranzitii si noduri
c. are rolul de a valida diagrame de clase
d. subliniaza ordinea mesajelor schimbate intre obiecte in functie de timp

3. Ciclul de viata al unui sistem informatic:

a. este cuprins in ciclul de dezvoltare al unui sistem informatic
b. este un sablon pentru ordonarea activitatilor de realizare a sistemului informatic
c. poate fi organizat in 5 etape (identificarea cerintelor, analiza, proiectare,
implementare, mentenanta)
d. se incheie cu decizia de abandonare a sistemului si inlocuirea lui cu un sistem nou

4. Este specific unei stari intr-o diagrama UML:

a. este inclusa in diagrama de clase
b. poate include actiuni speciale
c. este inclusa in diagrama de activitate
d. descrie un flux de lucru

6. Printre elementele de baza ale limbajului UML nu se numara (CURS 3 pag: 11-19)
a. meta-model pentur modelarea orientate obiect
b. procese de dezvoltare
c. diagrame
d. mecanisme deextensie

8. In limbajul BPMN, portile paralele(CURS 7 pag: 20)

a. sunt cunoscute sub denumirea de decizii
b. arata ca numai una din caile de iesire va fi urmata
c. verifica o conditie care sa duca la declansarea iesirilor
d. nu verifica nicio conditie care sa duca la declansarea iesirilor

9. Cu ajutorul diagramelor UML, nu se poate realiza: (CURS 3 pag: 18-19)

a. modelarea proceselor de afaceri
b. modelarea structurii statice
c. modelarea componentelor echipelor de lucru din organizatie
d. modelarea structurii dinamice

11. SI are urmatoarele caracteristici:(CURS 1 pag: 12)

a. este inclus in cadrul sistemului informational decizional
b. se ocupa de culegerea, stocarea si prelucrarea automata a datelor
c. include sistemul informational decizional
d. are rolul de a asista sau participa la procesul decizional

12. In limbajul BMPN, un eveniment:(CURS 7 pag: 8, 11)

a. reprezinta un obiect de conectare
b. afecteaza fluxul unui model
c. este atomic sau non-atomic
d. poate fi inclusiv sau exclusiv

13. O metodologie de realizare a unui sistem informatic trebuie sa cuprinda:(CURS 2

pag: 4)
a. detalii privind tehnologiile de implementare a SI
b. limbajele de programare utilizate
c. modalitatea de derulare a ciclului de viata al sistemului informatic
d. instrumente specifice de scriere de cod sursa

15. Diagrama de stare UML:(CURS 6 pag: 92)

a. modeleaza aspecte statice ale unei clase
b. modeleaza secvente de actiuni
c. modeleaza starea functionala a unui obiect
d. include stari si tranzitii

16. Metodologiile extreme programming (XP) si SCRUM se incadreaza in categoria

metodologiilor (CURS 2 pag: 35)
a. cu abordare orientata obiect
b. cu abordare structurala
c. bazate pe dezvoltare agila
d. bazate pe dezvoltare rapida (RAD)

17. Printre conceptele utilizate in realizarea SI se numara (CURS 2 pag: 2,3)

a. proces/etapa
b. activitate
c. ciclul de dezvoltare al sistemului
d. toate cele de mai sus

18. Reprezinta caracteristici ale diagramei de cazuri de utilizare (CURS 6 pag: 19)
a. descrie o multime de clase
b. include cazuri de utilizare, actori, clase si stari
c. descrie fluxul de activitati
d. produce un rezultat important pentru un actor

19. Printre trasaturile caracteristice ale modelarii, nu se numara:(CURS 7)

a. simplificarea
b. subordonarea la un scop
c. reprezentarea unui decident, a unei situatii care nu exista in realitate inca
d. divizarea si ierarhizarea

20. Intr-un nod decizional din diagrama de activitate (CURS 6 pag: 87)
a. fluxurile de iesire au conditii mutual exclusive
b. intra mai multe fluxuri si iese unul singur
c. intra mai multe fluxuri si ies mai multe fluxuri
d. se poate simula structura de control do-until din programare

SUBIECT NR 4 –DAT LA ZI DE LA ALEX

1. Video-formatul are ca si caracteristici (CURS 10 pag: 23)
a. este o colectie de obiecte si rutine care definesc interfetele aplicatiei
b. contine obiecte ce raspund la interactiunile utilizatorilor
c. contine obiecte ce raspund la evenimentele din sistem
d. cu ajutorul sau se pot insera sau sterge inregistrari din bd
e. permite afisarea datelor din baza de date

Combinatia corecta:
2. Construirea sistemului informatic presupune:(CURS 1 pag: 21-22)
a. identificarea cerintelor SI
b. analiza si poriectarea cerintelor sistemului
c. analiza si testarea programului
d. conducerea procesului de dezvoltare

3. Mentenanta preventiva a datelor:(CURS 12 pag: 22)

a. implica inlaturarea defectelor sau erorilor de proiectare
b. are rolul de a spori functionalitatea sistemului
c. implementeaza noi cerinte ale sistemului
d. reduce sau inlatura riscul caderii sistemului

4. Baza informationala din cadrul unui sistem informatic include:

a. programul cu ajutorul carora functioneaza sistemul
b. datele supuse prelucrarii
c. regulamentul de organizare si functionare
d. echipamente si tehnologii de comunicatie

5. O metodologie a unui SI nu trebuie sa cuprinda:: (CURS 2 pag: 4)

a. etapele de realizare a sistemului
b. strategia de normalizare a bazei de date
c. modalitatea de derulare a ciclului de viata
d. modalitatile de conducere a proiectului

6. Ciclul de dezvoltare a unui SI:(CURS 2 pag: 3)

a. include ciclul de viata
b. este inclus in ciclul de viata
c. cuprinde etape de analiza
d. cuprinde etape de mentananta
e. nu cuprinde etapa de proiectare

7. In limbajul BPMN, portile inclusive:(CURS 7 pag: 19)

a. pot declansa un singur rezultat
b. nu evalueaza conditii
c. pot declansa mai mult de un rezultat
d. au conditii numai exclusive

8. Diagrama de secventa:(CURS 6 pag: 64-70)

a. modeleaza aspecte statice ale sistemului
b. este o diagrama de interactiune
c. poate reprezenta logica procedurala
d. include mesaje de tip apel
e. include tranzitii intre starile obiectului

9. In BPM, etapa de optimizare presupune:(CURS 8 pag: 15)

a. identificarea structurii organizationale si a interactiunilor umane
b. identificarea pasilor care genereaza erori, intarzieri sau blocaje
c. stabilirea indicatorilor de performanta
d. identificarea subproceselor si obiectivelor

10. Elasticitatea este o cerinta impusa codurilor care sa permita:(CURS 10 pag: 30)
a. prelucrarea automata a datelor
b. realizarea cu usurinta a operatiilor de codificare
c. sugerarea cracateristicilor codificate
d. inserari si extensii ale nomenclatorului de coduri

11. La proiectarea arhitecturii sistemului informatic, se identifica: (CURS 9 pag: 5)

a. tipul bazei de date si al fisierelor
b. tipul tehnologiei informatice utilizate
c. tipul retelei si al protocolului de comunicatii
d. tipul metodologiei de dezvoltare folosite

12. Fluxul de mesaj in limbajul BPMN:(CURS 7 pag: 23)

a. descrie ordinea elementelor din flux
b. arata fluxul de informatii din proces
c. arata fluxul de mesaje intre doi participanti
d. traverseaza culoareleu unui con..

13. Obiectele de flux in limbajul BPMN includ:(CURS 7 pag: 11)

a. flux de secventa, flux de mesaj
b. flux de secventa, flux de mesaj, asociere
c. evenimentul, activitate, poarta
d. container, culoar

14. Metodologiile bazate pe dezvoltarea agila au ca dezavantaj:(CURS 2 pag: 36)

a. sunt potrivite pentru mediile care se schimba
b. nu ofera flexibilitate
c. ofera documentatie suficienta
d. depind mult de interactiunea cu beneficiarul

15. Editoarele de diagrame dintr-un instument CASE permit:(CURS 4 pag: 6)

a. stocarea obiectelor proiectului
b. generarea de cod
c. reprezentarea vizuala a unui sistem
d. crearea de prototipuri, de forme si rapoarte

16. Reprezinta un exemplu de specificatie prescriptiva:(CURS 5 pag: 8)

a. un client fidel va beneficia de o reducere de 20%
b. daca un produs nu e pe stoc, atunci nu poate fi livrat
c. daca stocul scade sub 10%, atunci se solicita reaprovizionarea
d. se livreaza gratuit comenzile de minim 200 RON

17. Reprezinta tehnici pentru identificarea cerintelor:(CURS 5 pag: 17-24)

a. interviurile, observatiile si analizele sociale
b. analiza, proiectarea, testarea
c. activitatile, datele, procesele
d. cazurile de utilizare, clasele, starile

18. Intre cazurile de utilizare pot exista relatii de:(CURS 6 pag: 24-26)
a. asociere, extindere, generalizare
b. asociere, agregare, calificare
c. includere, extindere, generalizare
d. asociere, agregare, compunere

19. Cerintele non-functionale ale unui sistem informatic:(CURS 5 pag: 10)

a. contin informatii privind procesarea si manipularea datelor
d. includ calcule
c. analizeaza operationalitatea sistemului
d. analizeaza datele sistemului

20. Limbajele semi-formale sunt cele pentru care pot fi verificabile:(CURS 3 pag: 7,8)
a. regulile de sintaxa si semantica
b. regulile de sintaxa, dar nu si de semantica
c. reguli de semantica, dar nu si de sintaxa
d. doar regulile de semantica

21. Metamodelul UML defineste concepte precum:(CURS 3 pag: 14)

a. tabela, tuplu, element
b. client, produs, factura
c. clasa, atribut, componenta
d. integer, real, boolean

22. Relatia de asociere intre clase este caracterizata prin:(CURS 6 pag: 46)
a. denumire, tip, numar, stari
b. denumire, atribute, stari, roluri
c. denumire, multiplicitati, roluri, directie de navigare
d. denumire, operatii, caracteristici, roluri

23. Agregarea compusa este:(CURS 6 pag: 50)

a. o forma slaba de agregare
b. o forma de dependenta
c. o forma de asociere binara
d. o forma de generalizare

24. Multiplicitatea la nivelul unui atribut al clasei descrie:(CURS 6 pag: 43)

a. cate instante poate avea clasa
b. daca atributul este read-only
c. cate valori poate lua un atribut
d. daca atributul are o valoare implicita

25. Instrumentele de tip CASE:(CURS 4 pag: 3-7)

a. pun accentul doar pe codificare si testare
b. pun accentul pe analiza si proiectare
c. permit realizarea unei documentatii de calitate
d. reduc timpul si costul de dezvoltare
e. includ editoare pentru diagrame

ALTE INTREBARI Nr. 1 DE LA IULIA

 1. Diagramele de activitate:(CURS 6 pag: 82)
a) Contin o descriere a vietii obiectelor unei clase
b) Reprezinta comportamentul intern al unui caz de utilizare
c) Descrie interactiunile dintre diverse obiecte ale unui sistem => diagram de obiecte
d) Pot fi folosite pentru a descrie procesare paralela

2. Ciclul de dezvoltare al unui sistem informatic cuprinde:(CURS 2 pag: 3)

a) Intervalul de timp cuprinds intre proiectarea si mentenanta sistemului
b) Intervalul de timp de la luarea deciziei de elaborare a unui sistem informatics si
pana la luarea deciziei de inlocuire a lui cu un alt sistem informatics
c) Intervalul de timp de la luarea deciziei de realizare a unui sistem pana la
introducerea sistemului in exploatare
d) Doar etapele de analiza si proiectare

3. Urmatoarele diagrame nu folosesc pentru reprezentarea lor obiecte ale claselor:

a) Diagramele de desfasurare
b) Diagramele de secventa
c) Diagramele de clase
d) Diagramele de obiecte

4. Care din urmatoarele variante constituie cerinte impuse codurilor:(CURS 10

pag: 30)
a) Unitate, stratificare
b) Stabilitate, elasticitate
c) Portabilitate, comunicare
d) Conciziune, operationalitate

5. Identificati variantele care sunt caracteristice sistemelor informatice pentru

managementul tactic:
a) Ajuta decidentul in activitatea sa
b) Utilizeaza baze de cunostinte si modele
c) Furnizeaza informatii conducerii executive
d) Folosesc abordarea sistemica pentru rezolvarea problemelor

6. Arhitectura orientate pe model:

a) Descrie modele independente si dependente de platforma
b) Propune cinci viziuni asupra unui sistem informatics
c) Are la baza transformari ale modelelor
d) Solicita construirea unor modele UML cat mai complete

7. Instrumentele de tip CASE pot sa asigure urmatoarele facilitate:

a) Suport pentru metode de analiza si proiectare
b) Stocarea si regasirea datelor din depozitul central
c) Generarea documentatiei de realizare
d) Generarea automata a codului pornind de la modelele conturate

ALTE INTREBARI Nr. 2DE LA IULIA

 1. In abordarea orientata obiect modelarea aspectelor statice ale unui sistem se
realizeaza prin:
a) Diagram de activitate
b) Diagram de secventa
c) Diagram de clase
d) Diagram de component

2. Care din urmatoarele variante constituie caracteristici ale sistemelor

informatice:
a) Este inclus in cadrul sistemului informational-decizional
b) Se ocupa de culegerea, stocarea si prelucrarea automata a datelor
c) Include sistemul informationl-decizional
d) Are rolul de a asista sau participa la procesul decisional

3. La proiectarea situatiilor cu rezultate finale machete:

a) Este reprezentarea de detaliu a unei situatii de iesire
b) Cuprinde antetul, titlul, elementele fixr, capul de tabl si date elementare
c) Contine specificatii care servesc utilizatorului
d) Contine specificatii care servesc programului

4. O metodologie de realizare a unui system informatics trebuie sa cuprinda:

a) Etapele si procesele de realizare
b) Detalii privind tehnologiile de implementare si limbajele de programare utilizate in
constructia SGBD
c) Tehnicile, procedurile, instrumentele, normele si standardele de utilizate
d) Regulile de formalizare a componentelor sistemului informatics

5. Diagramele de stare din UML:

a) Modeleaza aspectele functionale ale unui system
b) Descriu chronologic interactiunea dintre obiecte
c) Modeleaza starea dinamica a unui obiect specific
d) Contin linii de viata si stari compuse

6. Reprezinta caracteristici functionale ale sistemelor informatice executive:

a) Facilitatile de gestiune a resurselor umane
b) Facilitatile de agregare a datelor
c) Facilitatile de analiza a tendintelor
d) Facilitatile de gestiune a echipamentelor

7. In limbajul BPMN un eveniment are urmatoarele caracteristici:

a) Reprezinta un obiect de conexiune
b) Afecteaza fluxul unui model
c) Este atomic sau non-atomic
d) Controleaza convergenta unor fluxuri de control

Subiect Statistica Dumitrescu DE LA

IULIA
 1. Diagram de secvente:
a) Modeleaza aspect statice ale sistemului
b) Cuprinde stari, tranzitii si noduri
c) Are rolul de a valida diagram de clase
d) Subliniaza ordinea mesajelor schimbate intre obiecte in functie de timp

4. Este specific unei stari dintr-o diagram UML:

a) Este inclusa in diagram de clase
b) Poate include actiuni special
c) Este inclusa in diagram de activitate
d) Descrie un flux de lucru

6. Printre elementele de baza ale limbajului UML nu se numara:

a) Metamodel pentru modelarea orientate obiect
b) Procese de dezvoltare
c) Diagrame
d) Mecanisme de extensie

8. Cu ajutorul diagramelor UML se poate realiza:

a) Modelarea proceselor de afaceri
b) Modelarea structurii statice
c) Modelarea componentei echipelor de lucru din organizatie
d) Modelarea structurii dinamice

9. Sistemul informatics are urmatoarele caracteristici:

1. Este inclus in cadrul sistemului informational-decizional
2. Se ocupa de culegerea, stocarea si prelucrarea automata a datelor
3. Include sistemul informational-decizional
4. Are rolul de a asista sau participa la procesul decisional

13. O metodolgie de realizare a unui sistem informatics trebuie sa cuprinda:

a) Detalii privind tehnologiile de implementare a sistemului informatics
b) Limbajele de programare utilizate
c) Modalitatea de derulare a ciclului de viata a sistemului informatics
d) Instrumente specifice scrierii de cod sursa

16. Metodologiile Extreme Programming (XP) si SCRUM se incadreaza in categoria

metodologiilor:
a) Cu abordare orientate obiect
b) Cu abordare structurata
c) Bazate pe dezvoltare agila
d) Bazate pe dezvoltare rapida

17. Printre conceptele utilizate in realziarea sistemelor informatice se numara:

a) Process/etapa
b) Activitate
c) Ciclul de dezvoltare al sistemului
d) Toate cele de mai sus
19. Printre trasaturile caracteristice ale modelarii nu se Numara:
a) simplificarea
b) subordonarea la un scop
c) reprezentarea unui deziderat, a unei situatii care inca nu exista in realitate
d) divizarea si ierarhizarea

20. Intr-un nod decisional din diagram de activitate:

a) fluxurile de iesire au conditii mutual exclusive
b) intra mai multe fluxuri si iese unul singur
c) intra mai multe fluxuri si ies mai multe
d) se poate simula structura de control “DO-UNTIL” din programare

ALTE GRILE DE LA IULIA

1.Studiul iesirilor sistemului informational sub aspectul numarului de exemplare,
destinatiei fiecarui exemplar, corelatiilor logice dintre indicatori, algoritmilor ce stau la
baza elaborarii acestora, periodicitatea, frecventa, continutul informational, forma de
prezentare, poate folosi la:

a) proiectarea machetelor pentru iesirile sistemului informatic;

b) elaborarea diagramei de flux informational;
c) estimarea necesarului de hârtie de imprimanta;
d) elaborarea programelor;
e) estimarea eficientei economice a sistemului informatic.

Care dintre afirmatii este necorespunzatoare?

2. Capacitatea unui sistem de coduri reprezinta:

a) totalitatea simbolurilor distincte utilizate;

b) totalitatea combinatiilor distincte posibil de realizat din simbolurile ce compun
codul;
c) numarul de simboluri elementare din cod;
d) forma finala a codului cu precizarea clara a numarului de pozitii utilizate;
e) numarul de caractere utilizate pentru cifra de control.

3. Care din urmatoarele activitati sunt parcurse la realizarea unui sistem de coduri:
Curs 10- pag 36)

1. Identificarea multimii elementelor ce urmeaza a fi codificate;

2. Analiza sistemului decizional;
3. Uniformizarea terminologiei;
4. Uniformizarea datelor de intrare;
5. Alegerea tipului de cod;
6. Estimarea capacitatii de calcul;
 7. Determinarea cifrei de control;
8. Estimarea caracteristicilor codurilor;
9. Atribuirea codurilor elementelor multimii de codificat;
10. Intretinerea nomen-clatorului de coduri.

a)1, 2, 3, 7, 8; b) 1, 3, 5, 8, 9; c) 1, 4, 5, 6, 7;
d) 4, 5, 7, 8, 9; e) 1, 2, 3, 8, 9.

5. Sistemul informatic are ca obiectiv principal:

a) cresterea exactitatii si preciziei informatiilor;
b) asigurarea conducerii cu informatii reale si in timp util, necesare fundamentarii si
elaborarii operative a deciziilor;
c) cresterea gradului de incarcare a capacitatilor existente si reducerea duratei
ciclului de fabricatie
d) reducerea costului informatiei;
e) cresterea calitatii informatiilor

6. Cifra de control din cod este folosita pentru:

a) verificarea corectitudinii codului si corectia automata a acestuia in procesul de
culegere si transmitere a datelor;
b) verificarea datelor in procesul de culegere, transmitere, prelucrare si editare;
c) verificarea corectitudinii codului in procesul de culegere, transmitere si
prelucrare a datelor;
d) sortarea, interclasarea si prelucrarea datelor cu formare de grupe;
e) jonctiunea si inchiderea tranzitiva a datelor.

7. In etapa de proiectare detaliata a sistemelor informatice se realizeaza documentatia

pentru:
a) proiectul logic si fizic de ansamblu;
b) proiectul logic si de ansamblu;
c) proiectul logic si tehnic de detaliu;
d) documentatia de sistem;
e) manualul de prezentare al sistemului.

8. Conditiile de implementare a sistemelor informatice sunt:

1. difuzarea instructiunilor de executare a procedurilor;
2. dezvoltarea sistemului;
3. exploatarea sistemului;
4. asigurarea resurselor hardware;
5. asigurarea fondului informational;
6. asigurarea conditiilor organizatorice;
7. instruirea personalului utilizator;
8. elaborarea raportului de implementare.

a) 1, 4, 5, 6; b) 1, 4, 6, 8; c) 3, 4, 5, 7;

9. Studiul si analiza sistemului existent are ca obiectiv principal:

a) stabilirea cerintelor informationale ale conducerii;
b) cunoasterea sistemului de productie;
 c) cunoasterea sistemului decizional;
d) studiul fluxurilor tehnologice;
e) analiza structurilor organizatorice

10. Definitivarea documentatiei sistemului proiectat se realizeaza in etapa:

a) proiectarea de detaliu a sistemului informatic;
b) intretinerea sistemului informatic;
c) implementarea sistemului informatic;
d) receptionarea sistemului informatic;
e) dezvoltarea sistemului informatic.

11. Care din urmatoarele cerinte trebuie respectate la proiectarea unui sistem de coduri:
1. unicitate;
2. elasticitate;
3. operationalitate;
4. portabilitate;
5. fiabilitate;
6. mostenire;
7. capacitate de refacere a codului.

a) 1,2,4; b) 1,2,7; c) 3,5,6; d) 1,2,3; e) 4,5,6.

12. Studiul intrarilor sub aspectul sursei, destinatiei, periodicitatii, frecventei,

numarului de caractere ce urmeaza a fi preluate si stocate, forma de prezentare, conditii
de validare, folosesc la:
a) validarea datelor de intrare;
b) elaborarea diagramei de flux informational
c) estimarea volumului datelor de intrare;
d) estimarea vitezei de raspuns a sistemului;
e) estimarea necesarului de echipamente de culegere si transmitere a datelor.
Care dintre afirmatiile de mai sus nu este adevarata?

13. Schema functionala a fiecarui subsistem aplicatie informatica se elaboreaza in etapa:

a) proiectarea de ansamblu;
b) studiu si analiza sistemului existent;
c) conceperea sistemului informatic;
d) proiectarea de detaliu;
e) elaborarea programelor.

14. Care din urmatoarele criterii nu stau la baza evaluarii sistemului existent:
a) gradul de asigurare cu informatii necesare si suficiente a factorilor de decizie;
b) capacitatea sistemului informational de a sesiza tendintele in evolutia activitatii;
c) gradul de automatizare a operatiilor de culegere, prelucrare si transmitere a datelor;
d) evaluarea resurselor materiale, umane si financiare necesare realizarii
sistemului informatic;
e) posibilitatile de control si de efectuare de corectii ale sistemului.

15 Alegerea tipurilor de modele matematice ce urmeaza a fi utilizate de sistemul

informatic se face in etapa:
a) studiul si analiza sistemului existent;
 b) proiectarea de ansamblu;
c) proiectarea de detaliu;
d) elaborarea programelor;
e) implementarea sistemului informatic

16. Sistemul informatic este un ansamblu de:

a) elemente intercorelate functional pentru obtinerea manuala a informatiilor necesare
fundamentarii deciziilor;
b) functii elementare pentru fundamentarea deciziilor;
c) elemente necesare functionarii sistemului decizional;
d) elemente intercorelate functional functional pentru automatizarea procesului
de obtinere a informatiilor necesare fundamentarii deciziilor;
e) resurse necesare fundamentarii deciziilor.

17. Care din urmatoarele cerinte nu constituie un principiu de realizare a sistemelor

informatice:
a) fundamentarea conceperii sistemului informatic pe criterii de eficienta economica;
b) participarea nemijlocita a conducerii unitatii la conceperea sistemului
informatic;
c) adoptarea de solutii in concordanta cu resursele disponibile si cu restrictiile impuse;
d) realizarea proiectarii de ansamblu inaintea proiectarii de detaliu;
e) asigurarea unui nivel tehnic ridicat al solutiilor adoptate.

18. Care din urmatoarele obiective ale sistemului informatic nu afecteaza in mod direct
functionarea sistemului informational:
a) cresterea vitezei de raspuns a sistemului;
b) cresterea exactitatii si preciziei datelor;
c) reducerea costului informatiei;
d) cresterea prestigiului firmei;
e) cresterea completitudinii situatiilor de informare - raportare.

19. Prin "iesirile" unui sistem informatic se intelege totalitatea:

a) fisierelor din sistem;
b) datelor interne si externe;
c) imprimantelor si monitoarelor;
d) informatiilor furnizate de sistem beneficiarilor interni si externi;
e) informatiilor necesare actualizarii bazei de date.

20. Sistemul informatic urmareste in principal:

a) cresterea exactitatii si preciziei informatiilor;
b) asigurarea conducerii cu informatii reale si in timp util, necesare
fundamentarii si elaborarii operative a deciziilor;
c) cresterea gradului de incarcare a capacitatilor existente si reducerea duratei ciclului
de fabricatie;
d) reducerea costului informatiei;
e) cresterea calitatii informatiilor.

21. Documentatia elaborata la sfarsitul fiecarei etape de realizare a sistemului

informatic are, in principal, rolul de:
 a) asigurare a comunicarii intre echipele de specialisti implicati in realizarea
sistemului informatic;
b) prezentare a deficientelor sistemului actual;
c) sursa pentru elaborarea documentatiei "Raportul de implementare/ experimentare";
d) prezentare a variantelor de realizare a sistemului informatic;
e) indicare a fluxului de parcurgere a etapelor de realizare a sistemului informatic.

22. Care din urmatoarele activitati nu contribuie la realizarea (proiectarea) unui sistem
de coduri:
a) identificarea elementelor ce urmeaza a fi codificate;
b) precizarea si uniformizarea terminologiei;
c) alegerea tipurilor de coduri;
d) determinarea cifrei de control corespunzatoare fiecarui cod;
e) verificarea cifrei de control in procesul de prelucrare si transmitere a datelor.

23. Conform metodologiei SSADM, modelul logic al sistemului proiectat se obtine pe

baza:
a) cerintelor functionale si a modelului logic al sistemului existent;
b) catalogului cerintelor;
c) modelului fizic al sistemului existent;
d) modelului logic al sistemului existent;
e) cerintelor nefunctionale si a modelului logic al sistemului existent;

25 Tehnica concordantei intrari- iesiri privind analiza si proiectarea sistemelor

informatice nu ofera posibilitatea pentru:
a) definirea obiectivelor sistemului informatic;
b) proiectarea iesirilor sistemului informatic;
c) proiectarea intrarilor sistemului informatic;
d) definirea colectiilor de date;
e) corelarea iesirilor cu int rarile sistemului

26, Ce criterii se au în vedere în etapizarea activitatilor de realizare a sistemelor

informatice:
a) diferitele categorii de personal antrenate în activitatea de realizare a sistemelor
informatice precum si omogenitatea activitatilor de realizat;
b) diferitele categorii de personal antrenate în activitatea de realizare a sistemelor
informatice;
c) omogenitatea activitatilor de realizat;
d) omogenitatea activitatilor si fluxul thenologic de prelucrare a datelor;
e) nici un criteriu.

27. Proiectarea fizica de detaliu a intrarilor sistemului informatic presupune:

a) identificarea structurii logice a intrarilor si conditiilor de validare a datelor;
b) proiectarea videoformatelor de introducere a datelor;
c) definirea continutului documentelor si corelatiilor logice dintre caracteristicile
datelor de intrare;
d) proiectarea machetelor documentelor primare de pe care operatorul culege
datele;
e) specificarea sursei, numarului de exemplare, destinatiei fiecarui.
SUBIECT NR2.- DAT LA ZI DE LA ALEX
1. Instrumentele CASE:
a. se bazeaza pe definirea specificatiilor pe suport de hartie
b. urmaresc cresterea complexitatii procesului de proiectare a unui SI
c. ofera suport proiectantului in realizarea unui produs informatic
d. sunt folosite pentru stocarea, prelucrarea si generarea informatiilor necesare pentru
gestiunea activitatilor si pentru fundamentarea deciziilor

2. Diagrama de secvente:
a. modeleaza aspecte statice ale sistemului
b. cuprinde stari, tranzitii si noduri
c. are rolul de a valida diagrame de clase
d. subliniaza ordinea mesajelor schimbate intre obiecte in functie de timp

3. Ciclul de viata al unui sistem informatic:

a. este cuprins in ciclul de dezvoltare al unui sistem informatic
b. este un sablon pentru ordonarea activitatilor de realizare a sistemului informatic
c. poate fi organizat in 5 etape (identificarea cerintelor, analiza, proiectare,
implementare, mentenanta)
d. se incheie cu decizia de abandonare a sistemului si inlocuirea lui cu un sistem nou

4. Este specific unei stari intr-o diagrama UML:

a. este inclusa in diagrama de clase
b. poate include actiuni speciale
c. este inclusa in diagrama de activitate
d. descrie un flux de lucru

6. Printre elementele de baza ale limbajului UML nu se numara (CURS 3 pag: 11-19)
a. meta-model pentur modelarea orientate obiect
b. procese de dezvoltare
c. diagrame
d. mecanisme deextensie

8. In limbajul BPMN, portile paralele(CURS 7 pag: 20)

a. sunt cunoscute sub denumirea de decizii
b. arata ca numai una din caile de iesire va fi urmata
c. verifica o conditie care sa duca la declansarea iesirilor
d. nu verifica nicio conditie care sa duca la declansarea iesirilor

9. Cu ajutorul diagramelor UML, nu se poate realiza: (CURS 3 pag: 18-19)

a. modelarea proceselor de afaceri
b. modelarea structurii statice
c. modelarea componentelor echipelor de lucru din organizatie
d. modelarea structurii dinamice
11. SI are urmatoarele caracteristici:(CURS 1 pag: 12)
a. este inclus in cadrul sistemului informational decizional
b. se ocupa de culegerea, stocarea si prelucrarea automata a datelor
c. include sistemul informational decizional
d. are rolul de a asista sau participa la procesul decizional

12. In limbajul BMPN, un eveniment:(CURS 7 pag: 8, 11)

a. reprezinta un obiect de conectare
b. afecteaza fluxul unui model
c. este atomic sau non-atomic
d. poate fi inclusiv sau exclusiv

13. O metodologie de realizare a unui sistem informatic trebuie sa cuprinda:(CURS 2

pag: 4)
a. detalii privind tehnologiile de implementare a SI
b. limbajele de programare utilizate
c. modalitatea de derulare a ciclului de viata al sistemului informatic
d. instrumente specifice de scriere de cod sursa

15. Diagrama de stare UML:(CURS 6 pag: 92)

a. modeleaza aspecte statice ale unei clase
b. modeleaza secvente de actiuni
c. modeleaza starea functionala a unui obiect
d. include stari si tranzitii

16. Metodologiile extreme programming (XP) si SCRUM se incadreaza in categoria

metodologiilor (CURS 2 pag: 35)
a. cu abordare orientata obiect
b. cu abordare structurala
c. bazate pe dezvoltare agila
d. bazate pe dezvoltare rapida (RAD)

17. Printre conceptele utilizate in realizarea SI se numara (CURS 2 pag: 2,3)

a. proces/etapa
b. activitate
c. ciclul de dezvoltare al sistemului
d. toate cele de mai sus

18. Reprezinta caracteristici ale diagramei de cazuri de utilizare (CURS 6 pag: 19)
a. descrie o multime de clase
b. include cazuri de utilizare, actori, clase si stari
c. descrie fluxul de activitati
d. produce un rezultat important pentru un actor

19. Printre trasaturile caracteristice ale modelarii, nu se numara:(CURS 7)

a. simplificarea
b. subordonarea la un scop
c. reprezentarea unui decident, a unei situatii care nu exista in realitate inca
d. divizarea si ierarhizarea
20. Intr-un nod decizional din diagrama de activitate (CURS 6 pag: 87)
a. fluxurile de iesire au conditii mutual exclusive
b. intra mai multe fluxuri si iese unul singur
c. intra mai multe fluxuri si ies mai multe fluxuri
d. se poate simula structura de control do-until din programare

SUBIECT NR 4 –DAT LA ZI DE LA ALEX

1. Video-formatul are ca si caracteristici (CURS 10 pag: 23)
a. este o colectie de obiecte si rutine care definesc interfetele aplicatiei
b. contine obiecte ce raspund la interactiunile utilizatorilor
c. contine obiecte ce raspund la evenimentele din sistem
d. cu ajutorul sau se pot insera sau sterge inregistrari din bd
e. permite afisarea datelor din baza de date

Combinatia corecta:
2. Construirea sistemului informatic presupune:(CURS 1 pag: 21-22)
a. identificarea cerintelor SI
b. analiza si poriectarea cerintelor sistemului
c. analiza si testarea programului
d. conducerea procesului de dezvoltare

3. Mentenanta preventiva a datelor:(CURS 12 pag: 22)

a. implica inlaturarea defectelor sau erorilor de proiectare
b. are rolul de a spori functionalitatea sistemului
c. implementeaza noi cerinte ale sistemului
d. reduce sau inlatura riscul caderii sistemului

4. Baza informationala din cadrul unui sistem informatic include:

a. programul cu ajutorul carora functioneaza sistemul
b. datele supuse prelucrarii
c. regulamentul de organizare si functionare
d. echipamente si tehnologii de comunicatie

5. O metodologie a unui SI nu trebuie sa cuprinda:: (CURS 2 pag: 4)

a. etapele de realizare a sistemului
b. strategia de normalizare a bazei de date
c. modalitatea de derulare a ciclului de viata
d. modalitatile de conducere a proiectului

6. Ciclul de dezvoltare a unui SI:(CURS 2 pag: 3)

a. include ciclul de viata
b. este inclus in ciclul de viata
c. cuprinde etape de analiza
d. cuprinde etape de mentananta
e. nu cuprinde etapa de proiectare

7. In limbajul BPMN, portile inclusive:(CURS 7 pag: 19)

a. pot declansa un singur rezultat
b. nu evalueaza conditii
c. pot declansa mai mult de un rezultat
d. au conditii numai exclusive

8. Diagrama de secventa:(CURS 6 pag: 64-70)

a. modeleaza aspecte statice ale sistemului
b. este o diagrama de interactiune
c. poate reprezenta logica procedurala
d. include mesaje de tip apel
e. include tranzitii intre starile obiectului

9. In BPM, etapa de optimizare presupune:(CURS 8 pag: 15)

a. identificarea structurii organizationale si a interactiunilor umane
b. identificarea pasilor care genereaza erori, intarzieri sau blocaje
c. stabilirea indicatorilor de performanta
d. identificarea subproceselor si obiectivelor

10. Elasticitatea este o cerinta impusa codurilor care sa permita:(CURS 10 pag: 30)
a. prelucrarea automata a datelor
b. realizarea cu usurinta a operatiilor de codificare
c. sugerarea cracateristicilor codificate
d. inserari si extensii ale nomenclatorului de coduri

11. La proiectarea arhitecturii sistemului informatic, se identifica: (CURS 9 pag: 5)

a. tipul bazei de date si al fisierelor
b. tipul tehnologiei informatice utilizate
c. tipul retelei si al protocolului de comunicatii
d. tipul metodologiei de dezvoltare folosite

12. Fluxul de mesaj in limbajul BPMN:(CURS 7 pag: 23)

a. descrie ordinea elementelor din flux
b. arata fluxul de informatii din proces
c. arata fluxul de mesaje intre doi participanti
d. traverseaza culoareleu unui con..

13. Obiectele de flux in limbajul BPMN includ:(CURS 7 pag: 11)

a. flux de secventa, flux de mesaj
b. flux de secventa, flux de mesaj, asociere
c. evenimentul, activitate, poarta
d. container, culoar

14. Metodologiile bazate pe dezvoltarea agila au ca dezavantaj:(CURS 2 pag: 36)

a. sunt potrivite pentru mediile care se schimba
b. nu ofera flexibilitate
c. ofera documentatie suficienta
d. depind mult de interactiunea cu beneficiarul

15. Editoarele de diagrame dintr-un instument CASE permit:(CURS 4 pag: 6)

a. stocarea obiectelor proiectului
b. generarea de cod
c. reprezentarea vizuala a unui sistem
d. crearea de prototipuri, de forme si rapoarte

16. Reprezinta un exemplu de specificatie prescriptiva:(CURS 5 pag: 8)

a. un client fidel va beneficia de o reducere de 20%
b. daca un produs nu e pe stoc, atunci nu poate fi livrat
c. daca stocul scade sub 10%, atunci se solicita reaprovizionarea
d. se livreaza gratuit comenzile de minim 200 RON

17. Reprezinta tehnici pentru identificarea cerintelor:(CURS 5 pag: 17-24)

a. interviurile, observatiile si analizele sociale
b. analiza, proiectarea, testarea
c. activitatile, datele, procesele
d. cazurile de utilizare, clasele, starile

18. Intre cazurile de utilizare pot exista relatii de:(CURS 6 pag: 24-26)
a. asociere, extindere, generalizare
b. asociere, agregare, calificare
c. includere, extindere, generalizare
d. asociere, agregare, compunere

19. Cerintele non-functionale ale unui sistem informatic:(CURS 5 pag: 10)

a. contin informatii privind procesarea si manipularea datelor
d. includ calcule
c. analizeaza operationalitatea sistemului
d. analizeaza datele sistemului

20. Limbajele semi-formale sunt cele pentru care pot fi verificabile:(CURS 3 pag: 7,8)
a. regulile de sintaxa si semantica
b. regulile de sintaxa, dar nu si de semantica
c. reguli de semantica, dar nu si de sintaxa
d. doar regulile de semantica

21. Metamodelul UML defineste concepte precum:(CURS 3 pag: 14)

a. tabela, tuplu, element
b. client, produs, factura
c. clasa, atribut, componenta
d. integer, real, boolean

22. Relatia de asociere intre clase este caracterizata prin:(CURS 6 pag: 46)
a. denumire, tip, numar, stari
b. denumire, atribute, stari, roluri
c. denumire, multiplicitati, roluri, directie de navigare
d. denumire, operatii, caracteristici, roluri

23. Agregarea compusa este:(CURS 6 pag: 50)

a. o forma slaba de agregare
b. o forma de dependenta
c. o forma de asociere binara
d. o forma de generalizare

24. Multiplicitatea la nivelul unui atribut al clasei descrie:(CURS 6 pag: 43)

a. cate instante poate avea clasa
b. daca atributul este read-only
c. cate valori poate lua un atribut
d. daca atributul are o valoare implicita

25. Instrumentele de tip CASE:(CURS 4 pag: 3-7)

a. pun accentul doar pe codificare si testare
b. pun accentul pe analiza si proiectare
c. permit realizarea unei documentatii de calitate
d. reduc timpul si costul de dezvoltare
e. includ editoare pentru diagrame

ALTE INTREBARI Nr. 1 DE LA IULIA

8. Diagramele de activitate:(CURS 6 pag: 82)
e) Contin o descriere a vietii obiectelor unei clase
f) Reprezinta comportamentul intern al unui caz de utilizare
g) Descrie interactiunile dintre diverse obiecte ale unui sistem => diagram de obiecte
h) Pot fi folosite pentru a descrie procesare paralela

9. Ciclul de dezvoltare al unui sistem informatic cuprinde:(CURS 2 pag: 3)

e) Intervalul de timp cuprinds intre proiectarea si mentenanta sistemului
f) Intervalul de timp de la luarea deciziei de elaborare a unui sistem informatics si
pana la luarea deciziei de inlocuire a lui cu un alt sistem informatics
g) Intervalul de timp de la luarea deciziei de realizare a unui sistem pana la
introducerea sistemului in exploatare
h) Doar etapele de analiza si proiectare

10. Urmatoarele diagrame nu folosesc pentru reprezentarea lor obiecte ale claselor:
e) Diagramele de desfasurare
f) Diagramele de secventa
g) Diagramele de clase
h) Diagramele de obiecte

11. Care din urmatoarele variante constituie cerinte impuse codurilor:(CURS 10

pag: 30)
e) Unitate, stratificare
f) Stabilitate, elasticitate
g) Portabilitate, comunicare
h) Conciziune, operationalitate

12. Identificati variantele care sunt caracteristice sistemelor informatice pentru

managementul tactic:
e) Ajuta decidentul in activitatea sa
 f) Utilizeaza baze de cunostinte si modele
g) Furnizeaza informatii conducerii executive
h) Folosesc abordarea sistemica pentru rezolvarea problemelor

13. Arhitectura orientate pe model:

e) Descrie modele independente si dependente de platforma
f) Propune cinci viziuni asupra unui sistem informatics
g) Are la baza transformari ale modelelor
h) Solicita construirea unor modele UML cat mai complete

14. Instrumentele de tip CASE pot sa asigure urmatoarele facilitate:

e) Suport pentru metode de analiza si proiectare
f) Stocarea si regasirea datelor din depozitul central
g) Generarea documentatiei de realizare
h) Generarea automata a codului pornind de la modelele conturate

ALTE INTREBARI Nr. 2DE LA IULIA

8. In abordarea orientata obiect modelarea aspectelor statice ale unui sistem se
realizeaza prin:
e) Diagram de activitate
f) Diagram de secventa
g) Diagram de clase
h) Diagram de component

9. Care din urmatoarele variante constituie caracteristici ale sistemelor

informatice:
e) Este inclus in cadrul sistemului informational-decizional
f) Se ocupa de culegerea, stocarea si prelucrarea automata a datelor
g) Include sistemul informationl-decizional
h) Are rolul de a asista sau participa la procesul decisional

10. La proiectarea situatiilor cu rezultate finale machete:

e) Este reprezentarea de detaliu a unei situatii de iesire
f) Cuprinde antetul, titlul, elementele fixr, capul de tabl si date elementare
g) Contine specificatii care servesc utilizatorului
h) Contine specificatii care servesc programului

11. O metodologie de realizare a unui system informatics trebuie sa cuprinda:

e) Etapele si procesele de realizare
f) Detalii privind tehnologiile de implementare si limbajele de programare utilizate in
constructia SGBD
g) Tehnicile, procedurile, instrumentele, normele si standardele de utilizate
h) Regulile de formalizare a componentelor sistemului informatics

12. Diagramele de stare din UML:

e) Modeleaza aspectele functionale ale unui system
f) Descriu chronologic interactiunea dintre obiecte
 g) Modeleaza starea dinamica a unui obiect specific
h) Contin linii de viata si stari compuse

13. Reprezinta caracteristici functionale ale sistemelor informatice executive:

e) Facilitatile de gestiune a resurselor umane
f) Facilitatile de agregare a datelor
g) Facilitatile de analiza a tendintelor
h) Facilitatile de gestiune a echipamentelor

14. In limbajul BPMN un eveniment are urmatoarele caracteristici:

e) Reprezinta un obiect de conexiune
f) Afecteaza fluxul unui model
g) Este atomic sau non-atomic
h) Controleaza convergenta unor fluxuri de control

Subiect Statistica Dumitrescu DE LA

IULIA
2. Diagram de secvente:
e) Modeleaza aspect statice ale sistemului
f) Cuprinde stari, tranzitii si noduri
g) Are rolul de a valida diagram de clase
h) Subliniaza ordinea mesajelor schimbate intre obiecte in functie de timp

4. Este specific unei stari dintr-o diagram UML:

e) Este inclusa in diagram de clase
f) Poate include actiuni special
g) Este inclusa in diagram de activitate
h) Descrie un flux de lucru

6. Printre elementele de baza ale limbajului UML nu se numara:

e) Metamodel pentru modelarea orientate obiect
f) Procese de dezvoltare
g) Diagrame
h) Mecanisme de extensie

10. Cu ajutorul diagramelor UML se poate realiza:

e) Modelarea proceselor de afaceri
f) Modelarea structurii statice
g) Modelarea componentei echipelor de lucru din organizatie
h) Modelarea structurii dinamice

11. Sistemul informatics are urmatoarele caracteristici:

5. Este inclus in cadrul sistemului informational-decizional
6. Se ocupa de culegerea, stocarea si prelucrarea automata a datelor
7. Include sistemul informational-decizional
8. Are rolul de a asista sau participa la procesul decisional
13. O metodolgie de realizare a unui sistem informatics trebuie sa cuprinda:
e) Detalii privind tehnologiile de implementare a sistemului informatics
f) Limbajele de programare utilizate
g) Modalitatea de derulare a ciclului de viata a sistemului informatics
h) Instrumente specifice scrierii de cod sursa

16. Metodologiile Extreme Programming (XP) si SCRUM se incadreaza in categoria

metodologiilor:
e) Cu abordare orientate obiect
f) Cu abordare structurata
g) Bazate pe dezvoltare agila
h) Bazate pe dezvoltare rapida

17. Printre conceptele utilizate in realziarea sistemelor informatice se numara:

e) Process/etapa
f) Activitate
g) Ciclul de dezvoltare al sistemului
h) Toate cele de mai sus

19. Printre trasaturile caracteristice ale modelarii nu se Numara:

a) simplificarea
b) subordonarea la un scop
c) reprezentarea unui deziderat, a unei situatii care inca nu exista in realitate
d) divizarea si ierarhizarea

20. Intr-un nod decisional din diagram de activitate:

a) fluxurile de iesire au conditii mutual exclusive
b) intra mai multe fluxuri si iese unul singur
c) intra mai multe fluxuri si ies mai multe
d) se poate simula structura de control “DO-UNTIL” din programare

ALTE GRILE DE LA IULIA

1.Studiul iesirilor sistemului informational sub aspectul numarului de exemplare,
destinatiei fiecarui exemplar, corelatiilor logice dintre indicatori, algoritmilor ce stau la
baza elaborarii acestora, periodicitatea, frecventa, continutul informational, forma de
prezentare, poate folosi la:

a) proiectarea machetelor pentru iesirile sistemului informatic;

b) elaborarea diagramei de flux informational;
c) estimarea necesarului de hârtie de imprimanta;
d) elaborarea programelor;
e) estimarea eficientei economice a sistemului informatic.

Care dintre afirmatii este necorespunzatoare?

2. Capacitatea unui sistem de coduri reprezinta:

a) totalitatea simbolurilor distincte utilizate;

b) totalitatea combinatiilor distincte posibil de realizat din simbolurile ce compun
codul;
c) numarul de simboluri elementare din cod;
d) forma finala a codului cu precizarea clara a numarului de pozitii utilizate;
e) numarul de caractere utilizate pentru cifra de control.

3. Care din urmatoarele activitati sunt parcurse la realizarea unui sistem de coduri:
Curs 10- pag 36)

1. Identificarea multimii elementelor ce urmeaza a fi codificate;

2. Analiza sistemului decizional;
3. Uniformizarea terminologiei;
4. Uniformizarea datelor de intrare;
5. Alegerea tipului de cod;
6. Estimarea capacitatii de calcul;
7. Determinarea cifrei de control;
8. Estimarea caracteristicilor codurilor;
9. Atribuirea codurilor elementelor multimii de codificat;
10. Intretinerea nomen-clatorului de coduri.

a)1, 2, 3, 7, 8; b) 1, 3, 5, 8, 9; c) 1, 4, 5, 6, 7;
d) 4, 5, 7, 8, 9; e) 1, 2, 3, 8, 9.

5. Sistemul informatic are ca obiectiv principal:

a) cresterea exactitatii si preciziei informatiilor;
b) asigurarea conducerii cu informatii reale si in timp util, necesare fundamentarii si
elaborarii operative a deciziilor;
c) cresterea gradului de incarcare a capacitatilor existente si reducerea duratei
ciclului de fabricatie
d) reducerea costului informatiei;
e) cresterea calitatii informatiilor

6. Cifra de control din cod este folosita pentru:

a) verificarea corectitudinii codului si corectia automata a acestuia in procesul de
culegere si transmitere a datelor;
b) verificarea datelor in procesul de culegere, transmitere, prelucrare si editare;
c) verificarea corectitudinii codului in procesul de culegere, transmitere si
prelucrare a datelor;
d) sortarea, interclasarea si prelucrarea datelor cu formare de grupe;
e) jonctiunea si inchiderea tranzitiva a datelor.

7. In etapa de proiectare detaliata a sistemelor informatice se realizeaza documentatia

pentru:
a) proiectul logic si fizic de ansamblu;
 b) proiectul logic si de ansamblu;
c) proiectul logic si tehnic de detaliu;
d) documentatia de sistem;
e) manualul de prezentare al sistemului.

8. Conditiile de implementare a sistemelor informatice sunt:

1. difuzarea instructiunilor de executare a procedurilor;
2. dezvoltarea sistemului;
3. exploatarea sistemului;
4. asigurarea resurselor hardware;
5. asigurarea fondului informational;
6. asigurarea conditiilor organizatorice;
7. instruirea personalului utilizator;
8. elaborarea raportului de implementare.

a) 1, 4, 5, 6; b) 1, 4, 6, 8; c) 3, 4, 5, 7;

9. Studiul si analiza sistemului existent are ca obiectiv principal:

a) stabilirea cerintelor informationale ale conducerii;
b) cunoasterea sistemului de productie;
c) cunoasterea sistemului decizional;
d) studiul fluxurilor tehnologice;
e) analiza structurilor organizatorice

10. Definitivarea documentatiei sistemului proiectat se realizeaza in etapa:

a) proiectarea de detaliu a sistemului informatic;
b) intretinerea sistemului informatic;
c) implementarea sistemului informatic;
d) receptionarea sistemului informatic;
e) dezvoltarea sistemului informatic.

11. Care din urmatoarele cerinte trebuie respectate la proiectarea unui sistem de coduri:
1. unicitate;
2. elasticitate;
3. operationalitate;
4. portabilitate;
5. fiabilitate;
6. mostenire;
7. capacitate de refacere a codului.

a) 1,2,4; b) 1,2,7; c) 3,5,6; d) 1,2,3; e) 4,5,6.

12. Studiul intrarilor sub aspectul sursei, destinatiei, periodicitatii, frecventei,

numarului de caractere ce urmeaza a fi preluate si stocate, forma de prezentare, conditii
de validare, folosesc la:
a) validarea datelor de intrare;
b) elaborarea diagramei de flux informational
c) estimarea volumului datelor de intrare;
d) estimarea vitezei de raspuns a sistemului;
e) estimarea necesarului de echipamente de culegere si transmitere a datelor.
 Care dintre afirmatiile de mai sus nu este adevarata?

13. Schema functionala a fiecarui subsistem aplicatie informatica se elaboreaza in etapa:

a) proiectarea de ansamblu;
b) studiu si analiza sistemului existent;
c) conceperea sistemului informatic;
d) proiectarea de detaliu;
e) elaborarea programelor.

14. Care din urmatoarele criterii nu stau la baza evaluarii sistemului existent:
a) gradul de asigurare cu informatii necesare si suficiente a factorilor de decizie;
b) capacitatea sistemului informational de a sesiza tendintele in evolutia activitatii;
c) gradul de automatizare a operatiilor de culegere, prelucrare si transmitere a datelor;
d) evaluarea resurselor materiale, umane si financiare necesare realizarii
sistemului informatic;
e) posibilitatile de control si de efectuare de corectii ale sistemului.

15 Alegerea tipurilor de modele matematice ce urmeaza a fi utilizate de sistemul

informatic se face in etapa:
a) studiul si analiza sistemului existent;
b) proiectarea de ansamblu;
c) proiectarea de detaliu;
d) elaborarea programelor;
e) implementarea sistemului informatic

16. Sistemul informatic este un ansamblu de:

a) elemente intercorelate functional pentru obtinerea manuala a informatiilor necesare
fundamentarii deciziilor;
b) functii elementare pentru fundamentarea deciziilor;
c) elemente necesare functionarii sistemului decizional;
d) elemente intercorelate functional functional pentru automatizarea procesului
de obtinere a informatiilor necesare fundamentarii deciziilor;
e) resurse necesare fundamentarii deciziilor.

17. Care din urmatoarele cerinte nu constituie un principiu de realizare a sistemelor

informatice:
a) fundamentarea conceperii sistemului informatic pe criterii de eficienta economica;
b) participarea nemijlocita a conducerii unitatii la conceperea sistemului
informatic;
c) adoptarea de solutii in concordanta cu resursele disponibile si cu restrictiile impuse;
d) realizarea proiectarii de ansamblu inaintea proiectarii de detaliu;
e) asigurarea unui nivel tehnic ridicat al solutiilor adoptate.

18. Care din urmatoarele obiective ale sistemului informatic nu afecteaza in mod direct
functionarea sistemului informational:
a) cresterea vitezei de raspuns a sistemului;
b) cresterea exactitatii si preciziei datelor;
c) reducerea costului informatiei;
d) cresterea prestigiului firmei;
e) cresterea completitudinii situatiilor de informare - raportare.
19. Prin "iesirile" unui sistem informatic se intelege totalitatea:
a) fisierelor din sistem;
b) datelor interne si externe;
c) imprimantelor si monitoarelor;
d) informatiilor furnizate de sistem beneficiarilor interni si externi;
e) informatiilor necesare actualizarii bazei de date.

20. Sistemul informatic urmareste in principal:

a) cresterea exactitatii si preciziei informatiilor;
b) asigurarea conducerii cu informatii reale si in timp util, necesare
fundamentarii si elaborarii operative a deciziilor;
c) cresterea gradului de incarcare a capacitatilor existente si reducerea duratei ciclului
de fabricatie;
d) reducerea costului informatiei;
e) cresterea calitatii informatiilor.

21. Documentatia elaborata la sfarsitul fiecarei etape de realizare a sistemului

informatic are, in principal, rolul de:
a) asigurare a comunicarii intre echipele de specialisti implicati in realizarea
sistemului informatic;
b) prezentare a deficientelor sistemului actual;
c) sursa pentru elaborarea documentatiei "Raportul de implementare/ experimentare";
d) prezentare a variantelor de realizare a sistemului informatic;
e) indicare a fluxului de parcurgere a etapelor de realizare a sistemului informatic.

22. Care din urmatoarele activitati nu contribuie la realizarea (proiectarea) unui sistem
de coduri:
a) identificarea elementelor ce urmeaza a fi codificate;
b) precizarea si uniformizarea terminologiei;
c) alegerea tipurilor de coduri;
d) determinarea cifrei de control corespunzatoare fiecarui cod;
e) verificarea cifrei de control in procesul de prelucrare si transmitere a datelor.

23. Conform metodologiei SSADM, modelul logic al sistemului proiectat se obtine pe

baza:
a) cerintelor functionale si a modelului logic al sistemului existent;
b) catalogului cerintelor;
c) modelului fizic al sistemului existent;
d) modelului logic al sistemului existent;
e) cerintelor nefunctionale si a modelului logic al sistemului existent;

25 Tehnica concordantei intrari- iesiri privind analiza si proiectarea sistemelor

informatice nu ofera posibilitatea pentru:
a) definirea obiectivelor sistemului informatic;
b) proiectarea iesirilor sistemului informatic;
c) proiectarea intrarilor sistemului informatic;
d) definirea colectiilor de date;
 e) corelarea iesirilor cu int rarile sistemului

26, Ce criterii se au în vedere în etapizarea activitatilor de realizare a sistemelor

informatice:
a) diferitele categorii de personal antrenate în activitatea de realizare a sistemelor
informatice precum si omogenitatea activitatilor de realizat;
b) diferitele categorii de personal antrenate în activitatea de realizare a sistemelor
informatice;
c) omogenitatea activitatilor de realizat;
d) omogenitatea activitatilor si fluxul thenologic de prelucrare a datelor;
e) nici un criteriu.

27. Proiectarea fizica de detaliu a intrarilor sistemului informatic presupune:

a) identificarea structurii logice a intrarilor si conditiilor de validare a datelor;
b) proiectarea videoformatelor de introducere a datelor;
c) definirea continutului documentelor si corelatiilor logice dintre caracteristicile
datelor de intrare;
d) proiectarea machetelor documentelor primare de pe care operatorul culege
datele;
e) specificarea sursei, numarului de exemplare, destinatiei fiecarui.

Subiect nr2.
1.Instrumentele CASE:

a. se bazeaza pe definirea specificatiilor pe support de hartie

b. urmareste cresterea complexitatii procesului de proiectare a unui SI

c. ofera support proiectantului in realizarea unui produs informatic

d. sunt folosite pentru stoarea, prelucrarea si generarea informatiilor necesare pentru gestiunea
activitatilor si pentru fundamentarea deciziilor

2.Diagrama de secvente:

a. modeleaza aspect statice ale sistemului

b. cuprinde stari, tranzitii si noduri

c. are rol de a valida diagrame de clase

d. subliniaza ordinea mesajelor schimbate intre obiecte in functie de timp

3.Ciclul de viata al unui sistem informatic:

a. este cuprins in ciclul de dezvoltare al sistemului informtic

b. este un sablon pentru ordonarea activitatilor de realizare a sistemului informatics

c. poate fi organizat in 5 etape(identificarea cerintelor, analiza,proiectare,implementare,

mentenanta)

d. se incheie cu decizia de abandonare a sistemului si inlocuirea lui cu un system nou

Slectati variant corecta:

1. a+c+d
2. a+b
3. b+c+d
4. c+d

4.Este specific unei stari intr-o diagram UML:

a. este inclusa in diagram de clase

b. poate include actiuni special

c. este inclusa in diagram de activitate

d. descrie un flux de lucru

5.Acele limbaje pentru modelarea informational care au reguli stricte, iar sintaxa si semantic sunt
definite matematic, se numesc:

a. limbaje formale

b. limbaje informationale

c. limbaje semi-formale

d.limbaje de programare

6.Printre elementele de baza ale limbajului UML nu se numara:

a. meta-model pentru modelarea orientate obiect

b. procese de dezvoltare

c.diagrame

d. mecanisme de extensie
7.Agregarea partial are urmatoarele caracteristici:

a. este o forma puternica de agregare

b. se reprezinta sub forma unui romb plin

c. este o forma slaba de agregare

d. reprezinta o relatie de tip parinte-copil

8. In limbajul BPMN, portile paralele:

a. sunt cunoscute sub denumirea de decizii

b. arata ca numai una din caile de iesire va fi urmata

c. verifica o conditie care sa duca la declansarea iesirilor

d. nu verifica nicio conditie care sa duca la declansarea iesirilor

9.Cu ajutorul diagramelor UML, nu se poate realize:

a. modelarea proceselor de afaceri

b. modelarea structurii statice

c. modelarea componentelor echipelor de lucru din organizatie

d.modelarea structurii dinamice

10.Cerintele care defines functiile unui SI sau ale componentelor acestuia se numesc:

a. cerinte functionale

b. cerinte arhitecturale

c. cerinte de calitate

d. cerinte de dezvoltare

11. SI are urmatoarele caracteristici:

a. este inclus in cadrul sistemului informational decizional

b. se ocupa de culegerea, stocarea si prelucrarea automata a datelor

c. include sistemul informational decizional

d. are rolul de a asista sau participa la procesul decizional

Varianta corecta:

1.a,b,c

2.c,d

3.a,b,d

4.a,c,d

12. In limbajul BPMN, un eveniment:

a. reprezinta un obiect de conectare

b. afecteaza fluxul unui model

c. este atomic sau non-atomic

d. poate fi inclusiv sau exclusive

13. O metodologie de realizare a unui sistem informatic trebuie sa cuprinda:

a. detalii privind tehnologii de implementare a SI

b. limbajele de programare utilizate

c. modalitatea de derulare a ciclului de viata al sistemului infomatic

d. instrumente specific de scriere de cod sursa

14. Printre somponentele unui SI nu se afla:

a. sistemul informational

b. comunicatiile

c. software

d. utilizatorii

15. Diagrama de stare UML:

a. modeleaza aspect statice ale unei clase

b. modeleaza scvente de actiuni

c. modeleaza starea functional a unui obiect

d. include stari si tranzitii

16. Metodologiile extreme programming(XP) si SCRUM se incadreaza in categoria metodologiilor:

a. cu abordare orientate obiect

b. cu abordare structural

c. bazate pe dezvoltare agila

d. bazate pe dezvoltare rapida(RAD)

17. Printre conceptele utilizate in realizarea SI se numara:

a. process/etapa

b. activitae

c. ciclul de dezvoltare al sistemului

d. toate cele de mai sus

18. Reprezinta caracteristici ale diagramei de cazuri de utilizare:

a. descrie o multime de clase

b. include cazuri de utilizare, actori, clase si stari

c. descrie fluxul de activitati

d. produce un rezultat important pentru un actor

19. Printre tarsaturile carcateristice ale modelarii, nu se numara:

a. simplificrea

b. subordonarea la un scop
c. reprezentarea unui decident, a unei situatii care nu exista in realitate inca

d. divizarea si ierarhizarea

20. Intr-un nod decizional din diagram de activitate:

a. fluxurile de iesire au conditii mutual exclusive

b. intra mai multe fluxuri si iese unul singur

c. intra mai multe fluxuri si ies mai multe fluxuri

d. se poate simula structura de control do-until de programare

Subiect nr4.
1. Video-formatul are ca si caracteristici:
a. Este o colectie de obiecte si rutine care defines interfetele aplicatiei
b. Contine obiecte ce raspund la interactiuniunuile utilizatorului
c. Contine obiecte ce raspund la evenimentele din system
d. Cu ajutorul sau se pot insera sau sterge inregistrari in bd
e. Permite afisarea datelor din baza de date

Combinatia corecta:

a. B,c,d
b. A,b
c. A,b,c
d. A,b,c,d,e

2. Construirea sistemului informatic presupune:

a. Identificarea cerintelor SI
b. Analiza si proiectarea cerintelor sistemului
c. Analiza si tetarea programului
d. Conducerea procesului de dezvoltare

3. Mentenanta preventiva a datelor:

a. Implica inlaturarea defectelor sau erorilor de proiectare
b. Are rolul de a spori functionalitatea sistemului
 c. Implementeaza noi cerinte ale sistemului
d. Reduce sau inlatura riscul caderii sistemului

4. Baza informationala din cadrul unui sistem informatic include:

a. Programul cu ajutorul carora functioneaza sistemul
b. Datele supuse prelucrarii
c. Regulamentul de organizare si functionare
d. Echipamente si tehnologii de comunicatie

5. O metodologie a unui SI nu trebuie sa cuprinda:

a. Etapele de realizare a sistemului
b. Strategia de normalizare a bazei de date
c. Modalitatea de derulare a ciclului de viata
d. Modalitatile de conducere a proiectului

6. Ciclul de dezvoltare a unui SI:

a. Include ciclul de viata
b. Este inclus in ciclul de viata
c. Cuprinde etape de analiza
d. Cuprinde etape de mentenanta
e. Nu cuprinde etapa de proiectare

Combinatia corecta:

a. B,c
b. A,b,c
c. B,d,e
d. A,c,d,e

7. In limbajul BPMN, potile inclusive:

a. Pot declansa un singur rezultat
b. Nu evalueza conditii
c. Pot declansa mai mult de un rezultat
d. Au conditii numai exclusive

8. Diagrama de secventa:
a. Modeleaza aspecte statice ale sistemului
b. Este o diagrama de interactiune
 c. Poate reprezenta logica procedurala
d. Include mesaje de tip apel
e. Include tranzitii intre starile obiectului

Combinatia corecta:

a. B,c,d
b. B,c,d,e
c. A,b,c
d. B,d,e

9. In BPMN, etapa de optimizare presupune:

a. Identificarea structurii organizationale si a interactiuniunilor umane
b. Identificarea pasilor care genereaza erori, intarzieri sau blocaje
c. Stabilirea indicatorilor de performanta
d. Identificarea subproceselor si obiectivelor

10. Elasticitatea este o cerinta impusa codurilor care sa permita:

a. Prelucrarea automata a datelor
b. Realizarea cu usurinta a operatiilor de codificare
c. Sugerarea caracteristicilor codificate
d. Inserari si extensii ale nomenclatorului de coduri

11. La proiectarea arhitecturii sistemului informatic, se identifica:

a. Tipul bazei de date si al fisierelor
b. Tipul tehnologiei informatice utilizate
c. Tipul retelei si al protocolului de comunicatii
d. Tipul metodologiei de dezvoltare folosite

12. Fluxul de mesaj in limbajul BPMN:

a. Descrie ordinea elementelor din flux
b. Arata fluxul de informatii din proces
c. Arata fluxul de mesaje intre 2 participanti
d. Traverseaza culoarul unei con…

13. Obiectele de flux in limbajul BPMN include:

a. Flux de secventa, flux de mesaj
b. Flux de secventa, flux de mesaj, asociere
 c. Evenimentul, activitate, poarta
d. Container, culoar

14. Metodologiile bazate pe dezvoltarea agila au ca dezavantaj:

a. Sunt potrivite pentru mediile care se schimba
b. Nu ofera flexibilitate
c. Ofera documentatie suficenta
d. Depind mult de interactiunea cu beneficiarul

15. Editoarele de diagrame dintr-un instrument CASE permit:

a. Stocarea obiectelor proiectului
b. Generarea de cod
c. Reprezentarea vizuala a unui sistem
d. Crearea de prototipuri, de forme si rapoarte

16. Reprezinte un exemplu de specificatie prescriptiva:

a. Un client fidel va beneficia de o reducere de 20%
b. Daca un produs ne e pe stoc, atunci nu poate fi livrat
c. Daca stocul scade sub 10% atunci se solicita reaprovizionarea
d. Se livreaza gratuit comenzile de minim 200 RON

17. Reprezinta tehnici pentru identificarea cerintelor:

a. Interviurile, observatiile si analizele sociale
b. Analiza, proiectarea, testarea
c. Activitatile, datele, procesele
d. Cazurile de utilizare, clasele, starile

18. Intre cazurile de utilizare pot exista relatii de:

a. Asociere, extindere, generalizare
b. Asocoere, agregare, calificare
c. Includere, extindere, generalizare
d. Asociere, agregare, compunere

19. Cerintele non-functionale ale unui sistem informatic:

a. Contin informatii privind procesarea si manipularea datelor
b. Include calcule
 c. Analizeaza operationalitatea sistemului
d. Analizeaza datele sistemului

20. Limbajele semi-formale sunt cele pentru care pot fi verificabile:

a. Regulile de sintaxa si semantica
b. Regulile de sintaxa, dar nu si de semantica
c. Regulile de semantica, dar nu si de sintaxa
d. Doar regulile de semantica

21. Metamodelul UML defineste concepte precum:

a. Tabela, tuplu, element
b. Client, produs, factura
c. Clasa, atribut, componenta
d. Integer,real,boolean

22. Relatia de sociere intre clase este caracterizata prin:

a. Denumire, tip, numar, stari
b. Denumire, atribute, stari, roluri
c. Denumire, multiplicitati, roluri, directie de navigare
d. Denumire,operatii,caracteristici,roluri

23. Agregarea compusa este:

a. O forma slaba de agregare
b. O forma de dependenta
c. O forma de asociere binara
d. O forma de generalizare

24. Multiplicitatea la nivelul unui atribut al clasei descrie:

a. Cate instante poate avea clasa
b. Daca atributul este read-only
c. Cate valori poate lua un atribut
d. Daca atributul are o valoare implicita

25. Instrumentele de tip CASE:

a. Pun accentul doar pe codificare si testare
b. Pun accentul pe analiza si proiectare
 c. Permit realizarea unei documentatii de calitate
d. Reduc timpul si costul de dezvoltare
e. Include editoare pentru diagrame

Combinatia corecta:

a. B,c,d
b. B,c,d,e
c. A,b,c,
d. A,d,e

Subiect nr1.

1. Diagramele de activitate:
a. Contin o descriere a vietii obiectelor unei clase
b. Reprezinta comportamentul intern al unui caz de utilizare
c. Descrie interactiuniunile dintre diverse obiecte ale unui sistem =>
diadrama de obiecte
d. Pot fi folosite pentru a descrie procesare paralela

2. Ciclul de dezvoltare al unui sistem informatic cuprinde:

a. Intervalul de timp cuprins intre proiectarea si mentenanta sistemului
b. Intervalul de timp de la luarea deciziei de elaborare a unui sistem
informatic si pana la luarea deciziei de inlocuire a lui cu un alt sistem
informatic
c. Intervalul de timp de la luarea deciziei de realizare a unui sistem
pana la introducerea sistemului in exploatare
d. Doar etapele de analiza si proiectare
3. Urmatoarele diagrame nu folosesc pentru reprezentarea lor obiecte ale
claselor:
a. Diagramele de desfasurare
b. Diagramele de secventa
c. Diagramele de clase
d. Diagramele de obiecte

4. Care din urmatoarele varinate constiruie cerinte impuse codurilor:

a. Unitate, stratificare
b. Stabilitate, elasticitate
c. Portabilitate, comunicare
d. Conciziune,operationalitatea

5. Identificati variantele care sunt caracteristice sistemelor informatice

pentru managementul tactic:
a. Ajuta decidentul in activitatea sa
b. Utilizeaza baze de cunostiinte si modele
c. Furnizeaza informatii conducerii executive
d. Folosesc abordarea sistematica pentru rezolvarea problemelor

6. Arhitectura orientata pe model:

a. Descrie modele independente si dependente de platforma
b. Propune cinci viziuni asupra unui sistem informatic
c. Are la baza transformari ale modelelor
d. Solicita construira unor modele UML cat mai complete

7. Instrumentele de tip CASE pot sa asigure urmatoarele facilitati:

a. Suport pentru metode de analiza si proiectare
b. Stocarea si regasirea datelor din depozitul central
c. Generarea documentatiei de realizare
d. Generarea automata a codului pornind dela modelele conturate
ALTE INTREBARI

1. In abordarea orientata obiect modelarea aspectelor statistice ale unui sistem se realizeaza
prin:
a. Diagrama de activitate
b. Diagrama de secventa
c. Diagrama de clase
d. Diagrama de componente

2. Care din urmatoarele variante consttuie caracteristici ale sistemelor informatice:

a. Este inclus in cadrul sistemuluiinformational-decizional
b. Se ocupa de culegerea, stocarea si prelucrarea automata a datelor
c. Include sistemul informational-decizional
d. Are rolul de a asista sau participa la procesul decizional

3. La proiectarea situatiilor cu rezultate finale machete:

a. Este reprezentarea de detaliu a unei situatii de iesire
b. Cuprinde antetul. Titlul, elementele fixe, capul de tabel si date elementare
c. Contine specificatii care servesc utilizatorului
d. Contine specificatii care servesc programului

4. O metodologie de realizare a unui sistem informatic trebuie sa curpinda:

a. Etepele si procesele de realizare
b. Detalii privind tehnologiile de implementare si limbajele de programare utilizate in
constructia SGBD
c. Tehnicile, procedurile,instrumentele, normele si standardele de utilitate
d. Regulile de formalizare a componentelor sistemului informatic

5. DIagramele de stare din UML:

a. Modeleaza aspectele functionale ale unui sistem
b. Descriu cronologic interactiunea dintre obiecte
c. Modeleaza starea dinamica a unui obiect specific
d. Contin linii de viata si stari compuse

6. Reprezinta caracteristici functionale ale sistemelor informatice executive:

a. Facilitatile de gestiune a resurselor umane
b. Facilitatile de agregare a datelor
 c. Facilitaile de analiza a tendintelor
d. Facilitatile de gestiune a echipamentelor

7. In limbajul BPMN un eveniment are urmatoarele caracterisitici:

a. Reprezinta un obiect de conexiune
b. Afecteaza fluxul unui model
c. Este atomic sau non-atomic
d. Controloeaza convergenta unor fluxuri de control

8. Studiul iesirilor sistemului informational sub aspectul numarului de exemplare, destinatiei

fiecarui exemplar, corelatiilor logice dintre indicatori, algoritmilor ce stau la baza elaborarii
acestora, periodicitatea, frecventa, continutul informational,forma de prezentare, poate
folosi la:
c. estimarea necesarului de hartie de imprimanta
d. elaborarea programelor

9. Capacitatea unui sistem de coduri reprezinta:

b. totalitatea combinatiilor distincte posibil e realizat din simbolurile ce compun codul

10. Care din urmatoarele activitati sunt parcurse la realizarea unui sistem de coduri:
1.Identificarea multimii elementelor ce urmeaza a fi codificate
5.Alegerea tipului de cod
7.Determinarea ciferi de control
9.Atribuirea codurilor elementelor multimii de codificat
10. Intretinerea nomen-clatorului de coduri

11. Ciclul de viata al sistemului informatic:

a. Incepe cu decizia de realizare a sistemului informatic si se inchide cu decizia de
abandonare a acestuia in forma existenta si inlocuirea lui cu un nou sistem

12. Sistemul informatic are ca obiectiv principal:

a. Cresterea exactitatii preciziei informatiilor
b. Cresterea gradului de incarcare a capacitatilor existente si reducerea duratei ciclului de
fabricatie

13. Cifra de control din cod ete folosita pentru:

a. Verificarea corectitudintii codului in procesul de culegere, transmitere si prelucrare a
datelor

14. In etapa de proiectare detaliata a sistemelor informatice se realizeaza documentatia pentru:

 a. Proiectul logic si tehnic de detaliu

15. Conditiile de implementare a sistmelor informatice sunt:

a. Difuzarea instructiunilor de executare a procedurilor
b. Asigurarea fondului informational
c. Asigurarea conditiilor organizatorice
d. Instruirea personalului utilizator

16. Studiul si analiza sistemului existent are ca obiectiv principal:

a. Studiul fluxurilor tehnologice

17. Definitivarea documentatiei sistemului proiectat se realizeaza in etapa:

a. Implementarea sistemului informatic

18. Care din urmatoarele cerinte trebuie respectate la proiectarea unui sistem de coduri:
a. Unicitatea
b. Elasticitatea
c. Operationalitatea

19. Studiul intrarilor sub aspectul sursei, destinatiei, periodicitatii, frecventei, numarului de
caractere ce urmeaza a fi prelucrate si stocate, forma de prezentare, conditii de validare,
folosesc la:
a. Estimarea necesarului de echipamente de culegere si transmitere a datelor

20. Schema functionala a fiecarui subsitem aplicatie informatica se elaboreaza in etapa:

a. Proiectarea de detaliu

21. Care din urmatoarele criterii nu stau la baza evaluarii sistmului existent:
a. Evaluarea resurselor materiale, umane si financiare necesare realizarii sistemului
informatic

22. Alegerea tipurilor de modele matematice ce urmeaza a fi utilizate a sistemului informatic se

face in etapa:
a. Proiectarea de ansamblu

23. Sistemul infomatic este un ansamblu de:

a. Elemente intercorelate functional pt automatizarea procesului
b. Obtinere a informatiilor necesare fundamentarii deciziilor

24. Care din urmatoarele cerinte nu constituie un principiu de realizare a sistemelor:

 a. Participarea nemijlocita a conducerii unitatii la conceperea sistemului informatic
b. Asigurarea unui nivel tehnic ridicat al solutiilor adoptate

25. Care din urm obiective ale sistmului informatic nu afecteaza in mod direct functionarea
sistemului informational:
a. Cresterea prestigiului firmei

26. Prin “iesirile” unui sitem informatic se intelege totalitatea:

a. Informatiilor furnizate de sistem beneficiarilor interni si externi

27. Sistemul informatic urmareste in principal:

a. Asigurarea conducerii cu informatiile reale si in timp util, necesare fundamentarii si
elaborarii operative a deciziilor
28. Documentatia elaborata la sf fiecarei etape de realizare a sistemului informatie are,in
principal, rolul de:
a. Asigurare a comunicarii intre echipele de speciALISTI IMPLICATI IN REALIZARA SITEMULUI
INFORMATIC
b. PREZENTAREA A DEFICINTELOR SISTEMULUI ACTUAL

29. Caredin urm activitati nu contribuie la realizarea(proiectarea) unui sistem de coduri

a. Verificarea cifrei de control in procesul de prelucrare si transmitere a datelor

30. Conform metodologiei SSADM, modelul logic al sistemului proiectat se obtine pe baza:
A. cerintelor functionale si a modelului logic al sistemului existent

31. In cazul metodologiei SSADM, in etapa de proiectare a noului sistem, intrarile si iesirile pt
noul sistem se vor identifica din:
a. Diagrama de flux a datlor, nivelul funza, a modelului fizic al sistemului existent

32. Tehnica concordantei intrari- iesiri privind analiza si proiectarea sistemelor informatice nu
ofera posibilitatea pentru:
a. Definirea obiectivelor sistemului informatic

33. Ce criterii seau in vederein etapizarea activitatilor de realizare a sistemelor informatice:

 a. Diferitele categorii de personal antrenate in activitatea de realizare a sistemelor
informatice precum si omogentitatea activitatilor de realizat

34. Proiectarea fizica de detaliu a intrarilor sistemului informaticc presupune:

a. Proiectrea machetelor documentelor primare de pe care operatorul culege datele
b. PROIECTAREA SISTEMELOR INFORMATICE INTREBARI CU RASPUNSURI-EXAMEN
c.
d. Teste rezolvate Capitolul 1
e. 1. Care definiţie este corectă:
f. a) Un sistem reprezintă un ansamblu de elemente (componente) interdependente, între
care se
g. stabileşte o interacţiune dinamică, pe baza unor reguli prestabilite, cu scopul atingerii
unui
h. anumit obiectiv;
i. b) Un sistem reprezintă un ansamblu de identificatori care au rolul sa rezolve activităţi
specifice.
j. Răspuns: a
k.
l. 2. Sistemul informaţional cuprinde:
m. a) Ansamblul informaţiilor interne şi externe, formale sau informale utilizate în cadrul
firmei
n. precum şi datele care au stat la baza obţinerii lor;
o. b) Procedurile şi tehnicile de obţinere(pe baza datelor primare) şi de difuzare a
informaţiilor;
p. c) Platforma necesară prelucrării şi disipării informaţiilor;
q. d) Personalul specializat în culegerea, transmiterea, stocarea şi prelucrarea datelor.
r. Răspuns: a,b,c,d
s.
t. 3. Un sistem informatic este:
u. a) un sistem destinat conducerii unei organizaţii:
v. b) un sistem utilizator-calculator integrat, care furnizează informaţii pentru a sprijini
activităţile de la nivel operaţional şi activităţile de management într-o organizaţie,
utilizând echipamente hardware şi produse software, proceduri manuale, o bază de date
şi modele matematice pentru analiză, planificare, control şi luarea deciziilor:
w. c) un ansamblu structurat de elemente intercorelate funcţional pentru automatizarea
procesului de obţinere a informaţiilor şi pentru fundamentarea deciziilor.
x. Răspuns: b,c
y.
z. 4. Identificaţi afirmaţia falsă:
aa. a) Sistemul informaţional este subordonat sistemului de conducere.
bb. b) Sistemul informaţional face legătura între sistemul condus şi sistemul de conducere.
cc. c) Sistemul informatic este inclus în sistemul informaţional.
dd. d) Sistemul condus este subordonat sistemului informaţional.
ee. Răspuns: d
ff.
gg. 5. Sunt componente principale ale unui sistem informatic:
hh. a) Baza informaţională;
ii. b) Manager general;
jj. c) Baza tehnică;
kk. d) Baza ştiinţifică metodologică;
ll. e) Sistemul de programe.
mm. Răspuns: a,c,d,e
nn.
oo. 6. Obiectivul principal urmărit prin introducerea unui sistem informatic îl constituie:
pp. a) asigurarea conducerii cu informaţii reale şi în timp util necesare fundamentării şi
elaborării operative a deciziilor;
qq. b) asigurarea funcţionării normale si optime a activităţilor;
rr. c) creşterea productivităţii muncii;
ss. d) creşterea profitului;
tt. e) îmbunătăţirea imaginii unităţii economice.
uu. Răspuns: a
vv.
ww.
xx. 7. După domeniul de utilizare, sistemele informatice se clasifică în:
yy. a) Sisteme informatice pentru conducerea activităţilor economico-sociale;
zz. b) Sisteme informatice pentru conducerea proceselor tehnice;
aaa. c) Sisteme informatice şi expert;
bbb. d) Sisteme informatice pentru activităţi speciale.
ccc. Răspuns: a,b,d
ddd.
eee. 8. Sistemele informatice economice pot fi împărţite după modul de organizare a
datelor în:
fff. a) sisteme imagine;
ggg. b) sisteme bazate pe tehnica bazelor de date (ierarhice, reţea, relaţionale, orienatate-
obiect);
hhh. c) sisteme bazate pe algoritmi fundamentali;
iii. d) sisteme bazate pe fişiere.
jjj. Răspuns: b,d
kkk.
lll. 9. Ciclul prelucrării datelor pentru sistemul informatic cuprinde următoarele faze:
mmm. a) culegerea datelor;
nnn. b) pregătirea datelor;
ooo. c) prelucrarea datelor;
ppp. d) ştergerea datelor.
qqq. Răspuns: a,b,c
rrr.
sss. 10. În faza de întreţinere a fişierelor există mai multe activităţi, dintre care amintim:
ttt. a) memorarea(stocarea) datelor în vederea utilizării lor viitoare;
uuu. b) actualizarea datelor memorate astfel încât să surprindă cele mai recente
evenimente;
vvv.c) crearea datelor;
www. d) indexarea datelor pentru a înlesni o uşoară regăsire a lor;
xxx. e) protecţia datelor memorate, care cuprinde o mare varietate de proceduri şi tehnici
pentru prevenirea distrugerii lor sau a accesului neautorizat.
yyy.Răspuns: a,b,d,e
zzz.
aaaa. 11. Metodologiile de realizare a sistemelor informatice cuprind:
bbbb. a) reguli de formalizare a datelor;
cccc. b) instrumente pentru concepţia, realizarea şi elaborarea documentaţiei;
dddd. c) modalităţile de administrare a proiectului;
eeee. d) instrucţiuni pentru luarea deciziilor;
ffff. e) modalitatea de abordare a sistemelor.
gggg. Răspuns: a,b,c,e
hhhh.
iiii. 12. Reprezintă modul unitar sau manieră comună în care analiştii de sisteme,
programatorii şi alte categorii de persoane implicate realizează procesul de analiza a
sistemului informaţional-decizional existent, proiectarea şi introducerea sistemului
informatic:
jjjj. a) metodele utilizate în proiectarea sistemelor informatice;
kkkk. b) procedurile utilizate în proiectarea sistemelor informatice;
llll. c) tehnicile de lucru utilizate în proiectarea sistemelor informatice;
mmmm. d) instrumentele utilizate în proiectarea sistemelor informatice.
nnnn. Răspuns: a
oooo.
pppp. 13. Care din afirmaţiile următoare sunt corecte:
qqqq. a) Metoda top-down are ca obiectiv principal realizarea modularizării sistemului de
sus în jos.
rrrr. b) Metoda top-down constă în agregarea modulelor de jos în sus.
ssss. c) Metoda top-down nu are la bază principiul abordării sistemice.
tttt. Răspuns: a
uuuu.
vvvv. 14. Nu sunt faze ale ciclului de viaţă al dezvoltării sistemelor:
wwww. a) microanaliza;
xxxx. b) analiza;
yyyy. c) colectarea;
zzzz. d) proiectarea logică;
aaaaa. e) proiectarea fizică;
bbbbb. f) implementarea;
ccccc. g) întreţinerea.
ddddd. Răspuns: c
eeeee.
fffff. 15. Obiectivul principal al instrumentelor CASE este:
ggggg. a) Punerea în practică a produselor-program de proiectare şi realizare a softului cu
ajutorul calculatorului.
hhhhh. b) Simplificarea activităţilor de proiectare şi realizare a sistemelor/ aplicaţiilor.
iiiii. c) Aducerea în faţa analistului a problemelor supuse analizei.
jjjjj. d) Folosirea depozitelor modularizate.
kkkkk. Răspuns: a
lllll.
mmmmm. 16. Avantajele sistemelor CASE sunt:
nnnnn. a) exploatarea sistemului;
ooooo. b) creşterea vitezei de realizare a sistemelor;
ppppp. c) realizarea succesivă a componentelor unui sistem;
qqqqq. d) simplificarea activităţilor de proiectare şi realizare a sistemelor/aplicaţiilor.
rrrrr. Răspuns: b, c, d
sssss.
ttttt. 17. Instrumentele CASE se bazează pe:
uuuuu. a) o funcţie fundamentală;
vvvvv. b) două funcţii fundamentale;
wwwww. c) mai multe funcţii fundamentale.
xxxxx. Răspuns: b
yyyyy.
zzzzz. 18. Caracteristicile mediilor moderne de tip CASE sunt:
aaaaaa. a) integrarea;
bbbbbb. b) aranjarea;
cccccc. c) descompunerea;
dddddd. d) exploatarea.
eeeeee. Răspuns: a, c
ffffff.
gggggg. 19. Domeniile către care se orientează Upper CASE-ul, sunt:
hhhhhh. a) analiza cerinţelor sistemului;
iiiiii.b) proiectarea şi modelarea funcţională şi procedurală;
jjjjjj. c) modelarea datelor şi proiectarea bazei de date;
kkkkkk. d) generarea codurilor.
llllll.Răspuns: a, b, c, d
mmmmmm.
nnnnnn. 20. Nu sunt corecte următoarele afirmaţii:
oooooo. a) CASE reprezintă Proiectarea Sistemelor Asistată de Calculator;
pppppp. b) Instrumentele CASE implică utilizarea calculatorului ca un mijloc de
susţinere a activităţilor deplanificare, definire, proiectare şi realizare a softului.
qqqqqq. c) CASE reprezintă Proiectarea Sistemelor cu Ajutorul Calculatorului;
rrrrrr. d) CASE reprezintă Componente Asamblate ale Sistemelor Economice.
ssssss. Răspuns: d
tttttt.
uuuuuu. Întrebări şi răspunsuri
vvvvvv. 1. Enumeraţi tipurile de instrumente CASE după metodologia pe care o încorporează
pentru realizarea sistemelor.
wwwwww. Răspuns:
xxxxxx. - instrumente CASE bazate pe metodologia structurată;
yyyyyy. - instrumente hibride, ce conţin elemente specifice orientării-obiect, dar care nu
permit realizarea sistemelor orientate-obiect;
zzzzzz. - instrumente pur orientate-obiect.
aaaaaaa.
bbbbbbb. 2. Enumeraţi componentele produsului Westmount I-CASE Yourdon.
ccccccc. Răspuns:
ddddddd. Repository este componenta centrală a arhitecturii Westmount I-CASE
Yourdon. Repository este implementat cu
eeeeeee. ajutorul unui SGBD relaţional: Informix, Ingres sau Oracle.
fffffff. Analyst, este componenta ce oferă suport pentru analiza structurată şi anume:
editoare pentru diagrame de flux a
ggggggg. datelor, diagrame entitate asociere, diagrame de structură a datelor
editoarele matriciale pentru matricea listei de
hhhhhhh. evenimente.
iiiiiii. Arhitect este componenta ce permite definirea arhitecturii sistemului (proiectarea de
ansamblu). Designer este
jjjjjjj. componenta ce oferă suport pentru proiectarea de detaliu a sistemului informatic.
kkkkkkk. Proiectarea de detaliu a aplicaţiei este strâns legată de proiectarea bazei de
date. Pentru modelarea datelor se
lllllll. utilizează diagrama entitate asociere.
mmmmmmm. Programmer este mediul de programare care oferă suport pentru generarea
codului sursă, compilare, lansare în
nnnnnnn. execuţie şi testarea aplicaţiei. Generatorul de cod generează codul DDL (în
SQL) ce defineşte structura fizică a bazei
ooooooo. de date şi codul aplicaţiei în limbajul C îmbogăţit cu instrucţiuni SQL pornind
de la specificaţiile din schemele de
ppppppp. structură.
qqqqqqq. Docwriter este componenta care permite generarea documentaţiei pentru
fiecare etapă de realizare a sistemului.
rrrrrrr.
sssssss. 3. Instrumentele CASE orientate-obiect, din punct de vedere al etapelor ciclului de
viaţă al
ttttttt. sistemelor, pot fi grupate în instrumente:
uuuuuuu. Răspuns:
vvvvvvv. - Upper CASE orientat-obiect pentru analiza şi proiectarea sistemelor;
wwwwwww. - Lower CASE orientat-obiect pentru generarea codului-sursă al aplicaţiilor;
xxxxxxx. - I-CASE orientat-obiect care acoperă întregul ciclu de viaţă.
yyyyyyy. Întrebări
zzzzzzz. 1. Enumeraţi principalele activităţi din cadrul unei intreprinderi în vederea
identificării entităţilor
aaaaaaaa. bazei informaţionale.
bbbbbbbb. Prin analiza critică sunt identificate entită ţile bazei informaţionale. În
principal, pentru o
cccccccc. întreprindere acestea pot fi grupate după cum urmează :
dddddddd. - pentru activitatea de aprovizionare: stocuri de materiale, intră ri
materiale, consumuri de materiale,
eeeeeeee. contracte cu furnizorii, programe de aprovizionare;
ffffffff. - pentru activitatea de producţie: tehnologii ş i reţete de fabricaţie, program
de lucru, norme de muncă ş i
gggggggg. consumuri de manopere;
hhhhhhhh. - pentru activitatea de desfacere: stocuri de produse, contracte cu
clienţii, realiză ri contracte;
iiiiiiii. - pentru activitatea de marketing: evoluţia cererii ş i a ofertei, dinamica
preţurilor, elasticitatea cererii ş i
jjjjjjjj. a producţiei;
kkkkkkkk. - pentru activitatea financiar-contabilă : solduri ş i rulaje contabile,
calculaţia costurilor, bugete de
llllllll. venituri ş i cheltuieli, contabilitatea analitică ş i sintetică ;
mmmmmmmm. - pentru activitatea de personal: evidenţa personalului,
salariză ri, dotă ri social-culturale ş i gestiunea lor;
nnnnnnnn. - pentru activitatea de cercetare-dezvoltare: studii tehnico-
economice, proiecte tehnice, investiţii, etc.
oooooooo.
pppppppp. 2. Definiţi tipurile de reţele de calculatoare după aria de întindere geografică.
qqqqqqqq. - după aria de întindere geografică :
rrrrrrrr. - Locale =LAN (Local Area Network) – la nivelul unei organizaţii;
ssssssss. - Metropolitane –MAN (Metropolitan Area Network) – la nivel de
oraş , localitate;
tttttttt. - De mare întindere -WAN (World Area Network) (ex. Judeţ, Ţ ară ).
uuuuuuuu.
vvvvvvvv. 3. Definiţi tipurile de reţele de calculatoare după accesibilitate
wwwwwwww. - Internet (reţeaua Web) – o colecţie mondială de reţele
interconectate;
xxxxxxxx. - Intranet – un sit Web sau un grup de sit-uri care aparţin unei
organizaţii, accesibil numai
yyyyyyyy. pentru membrii acesteia;
zzzzzzzz. - Extranet – o reţea intranet care este parţial accesibilă utilizatorilor
externi autorizaţi.
aaaaaaaaa.
bbbbbbbbb. 4. Prezentaţi tipurile de echipamente care pot fi utilizate în cadrul unui sistem
informatic.
ccccccccc. Echipamente
ddddddddd. - Echipamente de calcul : calculatoare, staţii grafice, pentru servere
de reţea, servere de baze
eeeeeeeee. de date, staţii de lucru (clienţi, utilizatori), UPS-uri.
fffffffff. - Echipamente de comunicaţie : router-e, hub-uri, modem-uri, switch-uri.
ggggggggg.
hhhhhhhhh. 5. Enumeraţi produsele software de bază care pot fi utilizate pentru
realizarea unui sistem informatic.
iiiiiiiii. Produse software de bază :
jjjjjjjjj. - Sisteme de operare pentru serverul de reţea (UNIX, Windows NT server,
Windows 2000, Novell) ş i
kkkkkkkkk. pentru staţiile de lucru sau clienţi (Windows 95, Windows 98,
Windows NT work station, Windows
lllllllll. 2000);
mmmmmmmmm. - Sisteme de Gestiune a Bazelor de Date (ORACLE, SQL Server
Microsoft, MySQL, ACCESS, FoxPro
nnnnnnnnn. etc.);
ooooooooo. - Sisteme GIS (Geographical Information System) – utilizate pentru
realizarea aplicaţiilor din domeniul
ppppppppp. cadastrului (stocarea ş i prelucrarea datelor spaţiale );
qqqqqqqqq. - Limbaje (medii) de programare – utilizate pentru realizare software
de aplicaţie.
rrrrrrrrr.
sssssssss. 6. Definiţi ciclul de viaţă a unui sistem informatic.
ttttttttt. Sistemele informatice (SI) se caracterizează printr-un ciclu de viaţă
care începe cu decizia realiză rii
uuuuuuuuu. unui nou SI care să corespundă mai bine noilor cerinţe ale
utilizatorilor ş i se încheie cu decizia de
vvvvvvvvv. înlocuire a SI existent cu unul nou, mai performant. Ciclul de viaţă
se desfă ş oară pe etape în cadrul
wwwwwwwww. fiecă reia fiind definite faze ş i activită ţi specifice
xxxxxxxxx.
yyyyyyyyy. 7. Enumeraţi etapele ciclului de viaţă a unui sistem informatic în modelul
cascadă.
zzzzzzzzz. ale ciclului de viaţă a unui sistem informatic în modelul cascadă ([10])
aaaaaaaaaa. 1. Analiza şi definirea cerinţelor – sunt definite scopurile, serviciile ş i
restricţiile pe care trebuie
bbbbbbbbbb. să le îndeplinească sistemul informatic, prezentate într-o manieră
încât să poată fi înţelese atât de că tre
cccccccccc. utilizatorii sistemului cât ş i de personalul de proiectare.
dddddddddd. 2. Proiectarea sistemului şi software-ului – satabilirea cerinţelor
pentru hardware ş i software ş i
eeeeeeeeee. elaborarea arhitecturii generale a sistemului. Funcţiile sistemului
informaţional vor fi reprezentate astfel
ffffffffff. încât să poată fi tranformate în unul sau mai multe programe
executabile.
gggggggggg. 3. Implementarea şi testarea unităţilor de program – proiectarea
software-ului din etapa
hhhhhhhhhh. anterioară este transpusă într-o mulţime de programe sau module
programş i verificarea faptului că fiecare
iiiiiiiiii. program sau modul satisface specificaţia sa.
jjjjjjjjjj. 4. Integrarea şi testarea sistemului – integrarea ş i testarea programelor ş i
modulelor program ca
kkkkkkkkkk. un sistem complet pentru a ne asigura că cerinţele informaţionale
sunt satisfă cute. După testare sistemul
llllllllll. este livrat beneficiarului.
mmmmmmmmmm. 5. Exploatarea şi întreţinerea sistemului – este faza în care
sistemul informatic este efectiv
nnnnnnnnnn. utilizat de că tre beneficiar ş i în care sunt descoperite ş i rezolvate
eventuale erori de proiectare ş i
oooooooooo. programare ş i omisiuni în cerinţele informaţionale iniţiale.
pppppppppp.
qqqqqqqqqq. 8. Enumeraţi metodologiile utilizate în funcţie de modul de abordare şi
domeniul de aplicabilitate
rrrrrrrrrr. În funcţie de modul de abordare ş i domeniul de aplicabilitate,
metodologiile utilizate sunt:
ssssssssss. - metodologii din domeniul gestiunii: AXIAL (firma IBM), MERISE
(Ministerul industriei-Franta),
tttttttttt. IE (James Martin), SSADM (Marea Britanie);
uuuuuuuuuu. - metodologii orientate obiect: OMT (General Electric -SUA), OOD
(Michael Jackson);
vvvvvvvvvv. - metodologii pentru conducerea proiectelor de sisteme inform
wwwwwwwwww.
xxxxxxxxxx. 9. Enumeraţi cele 4 nivele care pot fi identificate în organigrama unei unităţi
economice Productive.
yyyyyyyyyy. Pentru unităţi economice productive în organigramă se disting
urmă toarele patru nivele de
zzzzzzzzzz. reprezentare [10]:
aaaaaaaaaaa. - nivelul conducerii strategice, reprezentat de directorul general ş i
consiliul de administraţie;
bbbbbbbbbbb. - nivelul conducerii tactice (directori pe funcţiuni);
ccccccccccc. - nivelul compartimentelor funcţionale (servicii ş i posturi de lucru) ş i
de proiectare, cercetare
ddddddddddd. (laboratoare) care asigură conducerea operativă a sistemului
prin ş efii lor;
eeeeeeeeeee. - nivelul compartimentelor de producţie (secţii, ateliere) care
realizează funcţia de producţie a
fffffffffff. sistemului economic.
ggggggggggg.
hhhhhhhhhhh. Capitolul 2
iiiiiiiiiii. 1. Propunerile pentru identificarea proiectelor de dezvoltare sunt făcute de:
jjjjjjjjjjj. a) top-managerii;
kkkkkkkkkkk. b) personalul auxiliar;
lllllllllll. c) muncitori;
mmmmmmmmmmm. d) departamentul utilizatorilor.
nnnnnnnnnnn. Răspuns: a, d
ooooooooooo.
ppppppppppp. 2. Selecţia proiectelor de dezvoltare a sistemelor informaţionale, urmăreşte:
qqqqqqqqqqq. a) atingerea obiectivelor organizaţiei;
rrrrrrrrrrr. b) bunul mers a informaţiei;
sssssssssss. c) creşterea duratei de implementare.
ttttttttttt. Răspuns: a
uuuuuuuuuuu.
vvvvvvvvvvv. 3. Care nu sunt activităţile efectuate în faza iniţierii proiectului:
wwwwwwwwwww. a) stabilirea echipei de iniţiere a proiectului;
xxxxxxxxxxx. b) stabilirea bunelor relaţii cu beneficiarii;
yyyyyyyyyyy. c) stabilirea planului iniţierii proiectului;
zzzzzzzzzzz. d) stabilirea procedurilor manageriale;
aaaaaaaaaaaa. e) stabilirea cerinţelor sistemului.
bbbbbbbbbbbb. Răspuns: e
cccccccccccc.
dddddddddddd. 4. Tipurile activităţilor executate în cadrul planificării proiectului
cuprind:
eeeeeeeeeeee. a) Descrierea ariei de întindere, a variantelor şi fezabilităţii proiectului;
ffffffffffff. b) Descompunerea proiectului în activităţi uşor executabile şi controlabile;
gggggggggggg. c) Crearea bazei de date;
hhhhhhhhhhhh. d) Crearea unui buget preliminar;
iiiiiiiiiiii. e) Implementarea proiectului.
jjjjjjjjjjjj. Răspuns: a, b, d
kkkkkkkkkkkk.
llllllllllll. 5. Următoarele afirmaţii sunt corecte:
mmmmmmmmmmmm. a) Un studiu de fezabilitate are rolul de a asigura informaţiile
obiective necesare pentru a cunoaşte dacă un proiect poate fi demarat sau nu, sau dacă
un proiect deja început mai poate fi continuat;
nnnnnnnnnnnn. b) Studiul de fezabilitate face parte din etapa de întreţinere a
sistemelor;
oooooooooooo. c) Diagrama Gantt este o modalitate de reprezentare grafică a
proiectului.
pppppppppppp. Răspuns: a, c
qqqqqqqqqqqq.
rrrrrrrrrrrr. 6. Studiile de fezabilitate trebuie să conţină:
ssssssssssss. a) Definirea problemei (o scurtă descriere a proiectului şi explicarea a ceea
ce-şi propune el să realizeze);
tttttttttttt. b) Descrierea cerinţelor sistemului;
uuuuuuuuuuuu. c) Explicaţia critică a motivării studiului întreprins;
vvvvvvvvvvvv. d) Cuantificarea tuturor costurilor materiale şi beneficiilor aferente.
wwwwwwwwwwww. Răspuns: a, b, c, d
xxxxxxxxxxxx.
yyyyyyyyyyyy. 7. Diagramele Gantt se utilizează pentru:
zzzzzzzzzzzz. a) reprezentarea ordinii activităţilor desfăşurate pentru realizarea proiectului;
aaaaaaaaaaaaa. b) reprezentarea grafică a proiectului;
bbbbbbbbbbbbb. c) descrierea proiectelor simple sau a unor componente ale
proiectelor mari;
ccccccccccccc. d) monitorizarea stadiului realizării activităţilor planificate.
ddddddddddddd. Răspuns: b, c, d
eeeeeeeeeeeee. Teste rezolvate Capitolul 3
fffffffffffff. 1. Studiul sistemului existent constă în:
ggggggggggggg.a) studiul activităţilor de bază desfăşurate de sistem;
hhhhhhhhhhhhh. b) identificarea metodelor si mijloacelor tehnice;
iiiiiiiiiiiii. c) definirea caracteristicilor generale ale sistemului;
jjjjjjjjjjjjj. d) definirea direcţiilor de perfecţionare ale actualului sistem;
kkkkkkkkkkkkk. e) studiul sistemului de conducere.
lllllllllllll. Răspuns: a, b, c, e
mmmmmmmmmmmmm.
nnnnnnnnnnnnn. 2. Activitatea de determinare a cerinţelor sistemului se concretizează
în diferite forme ale informaţiilor
ooooooooooooo. colectate, cum sunt:
ppppppppppppp. a) copii ale interviurilor;
qqqqqqqqqqqqq. b) realizarea programului;
rrrrrrrrrrrrr. c) implementarea sistemului;
sssssssssssss. d) interpretări ale răspunsurilor la chestionare.
ttttttttttttt. Răspuns: a, d
uuuuuuuuuuuuu.
vvvvvvvvvvvvv. 3. Definirea caracteristicilor generale ale sistemului economic implică:
wwwwwwwwwwwww. a) cunoaşterea profilului, obiectivelor agentului economic;
xxxxxxxxxxxxx. b) cunoaşterea locului în sfera serviciilor şi sfera producţiei;
yyyyyyyyyyyyy. c) cunoaşterea relaţiilor de cooperare cu alţi agenţi economici;
zzzzzzzzzzzzz. d) cunoaşterea specificului activităţii de bază ( producţie, servicii).
aaaaaaaaaaaaaa. Răspuns: a, b, c, d
bbbbbbbbbbbbbb.
cccccccccccccc. 4. Studiul sistemului de conducere se referă la identificarea:
dddddddddddddd. a) caracteristicilor rezultate din statutul de funcţionare a societăţii,
tipuri de decizii, modul de luare a deciziilor;
eeeeeeeeeeeeee. b) principalilor algoritmi, reguli de calcul şi de control;
ffffffffffffff. c) mijloacelor tehnice existente în dotarea unităţii economice;
gggggggggggggg. d) modului de organizare a producţiei.
hhhhhhhhhhhhhh. Răspuns: a
iiiiiiiiiiiiii.
jjjjjjjjjjjjjj. 5. Metodele tradiţionale de determinare a cerinţelor sistemelor sunt:
kkkkkkkkkkkkkk. a) interviul;
llllllllllllll. b) prototipizarea;
mmmmmmmmmmmmmm. c) Joint Application Design (JAD);
nnnnnnnnnnnnnn. d) chestionarul.
oooooooooooooo. Răspuns: a, b, d
pppppppppppppp.
qqqqqqqqqqqqqq. 6. Paşii prototipizării sunt:
rrrrrrrrrrrrrr. a) Identificarea cerinţelor principale ale sistemului;
ssssssssssssss. b) Realizarea prototipului iniţial;
tttttttttttttt. c) Proces iterativ de adaptare a sistemului la cerinţele utilizatorului;
uuuuuuuuuuuuuu. d) Folosirea sistemului aprobat de utilizatori.
vvvvvvvvvvvvvv. Răspuns: a, b, c, d
wwwwwwwwwwwwww.
xxxxxxxxxxxxxx. 7. Scopul diagramelor de date DFD este de a scoate în relief, într-o manieră
cât mai sugestivă,următoarele aspecte:
yyyyyyyyyyyyyy. a) sursa datelor de prelucrare;
zzzzzzzzzzzzzz. b) macheta datelor de prelucrare;
aaaaaaaaaaaaaaa. c) destinaţia datelor prelucrate;
bbbbbbbbbbbbbbb. d) legătura existentă între prelucrări şi activitatea de stocare a
datelor.
ccccccccccccccc. Răspuns: a, c, d
ddddddddddddddd.
eeeeeeeeeeeeeee. 8. Identificaţi afirmaţia falsă:
fffffffffffffff. a) Diagrama de context scoate în evidenţă aria de întindere a sistemului
analizat;
ggggggggggggggg. b) Diagrama fluxului de date ale nivelului logic curent, independentă
de tehnologie, reliefează funcţiile de prelucrare a datelor executate de către sistemul
informaţional curent;
hhhhhhhhhhhhhhh. c) Diagrama de flux de date ale sistemului logic nou va prezenta
circuitul datelor, structura lor şi cerinţele funcţionale ale noului sistem;
iiiiiiiiiiiiiii. d) Diagrama fluxului de date prezintă modelarea conceptuală a datelor.
jjjjjjjjjjjjjjj. Răspuns: d
kkkkkkkkkkkkkkk.
lllllllllllllll. 9. Simbolul folosit în diagramele DFD realizate cu SSADM (Structured Systems
Analysis and Design
mmmmmmmmmmmmmmm. Methodology), pentru reprezentarea fluxului de date sunt:
nnnnnnnnnnnnnnn. c) săgeată;
ooooooooooooooo. a) elipsă;
ppppppppppppppp. b) cerc.
qqqqqqqqqqqqqqq. Răspuns: a
rrrrrrrrrrrrrrr.
sssssssssssssss. 10. Câte entităţi externe conţine diagrama de context pentru aplicaţia
Decontări:

ttttttttttttttt.
uuuuuuuuuuuuuuu. a) patru entităţi;
vvvvvvvvvvvvvvv. b) cinci entităţi;
wwwwwwwwwwwwwww. c) nici o entitate.
xxxxxxxxxxxxxxx. Răspuns: b
yyyyyyyyyyyyyyy. 11 Raportul detaliat al cerinţelor sistemului conţine următoarele
elemente:
zzzzzzzzzzzzzzz. a) refacerea analizelor pentru întregul sistem;
aaaaaaaaaaaaaaaa. b) descrierea şi prezentarea unui exemplar al tuturor intrărilor în
sistem, inclusiv numele fiecărei intrări, sursa, cine îl completează, ce date va conţine şi
cum vor fi culese datele;
bbbbbbbbbbbbbbbb. c) o descriere şi un model de exemplar pentru fiecare ieşire din
sistem (rapoarte, documente).
cccccccccccccccc. Răspuns: b, c
dddddddddddddddd.
eeeeeeeeeeeeeeee. 12. Principalele elemente ale documentaţiei elaborate pentru
modelarea logicii proceselor sunt:
ffffffffffffffff. a) reprezentarea în engleza structurată;
gggggggggggggggg. b) reprezentarea logicii proceselor prin tabele de decizie;
hhhhhhhhhhhhhhhh. c) reprezentarea prin diagrame entitate-relaţie;
iiiiiiiiiiiiiiii. d) reprezentarea logicii proceselor prin arbori de decizie;
jjjjjjjjjjjjjjjj. e) tabelul sau diagrama stărilor de tranziţie.
kkkkkkkkkkkkkkkk. Răspuns: a, b, d, e
llllllllllllllll.
mmmmmmmmmmmmmmmm. 13. Cea mai cunoscută formă utilizată pentru
modelarea conceptuală a datelor este:
nnnnnnnnnnnnnnnn. a) diagrama entitate-relaţie (DER);
oooooooooooooooo. b) diagrama fluxului de date (DFD);
pppppppppppppppp. c) diagrama stărilor de tranziţie.
qqqqqqqqqqqqqqqq. Răspuns: a
rrrrrrrrrrrrrrrr.
ssssssssssssssss. 14. În DER pentru fiecare entitate reprezentată se apelează la
simbolul:
tttttttttttttttt. a) cerc;
uuuuuuuuuuuuuuuu. b) săgeată;
vvvvvvvvvvvvvvvv. c) romb;
wwwwwwwwwwwwwwww. d) dreptunghi.
xxxxxxxxxxxxxxxx. Răspuns: d
yyyyyyyyyyyyyyyy.
zzzzzzzzzzzzzzzz. 15. Nu sunt tipuri de relaţii:
aaaaaaaaaaaaaaaaa. a) relaţia unu-la-unu; b) relaţia unu-la-multe;
bbbbbbbbbbbbbbbbb. c) relaţia absolută; d) relaţia unei entităţi cu ea însăşi.
ccccccccccccccccc. Răspuns: c
ddddddddddddddddd.
eeeeeeeeeeeeeeeee. 16. Care din afirmaţiile următoare sunt adevărate:
fffffffffffffffff. a) O cheie-primară este o cheie-candidat care a fost selectată pentru a servi
ca identificator de cazuri în cadrul unui tip de entitate.
ggggggggggggggggg. b) Entităţile sunt obiecte sau evenimente (fenomene sau procese
economice, în cazul nostru).
hhhhhhhhhhhhhhhhh. c) Un atribut este o proprietate sau o caracteristică a unei entităţi
care prezintă interes pentru organizaţie.
iiiiiiiiiiiiiiiii. Răspuns: a, b, c
jjjjjjjjjjjjjjjjj.
kkkkkkkkkkkkkkkkk. Întrebări
lllllllllllllllll. 1. Enumeraţi metode moderne de analiză şi determinarea cerinţelor
sistemului.
mmmmmmmmmmmmmmmmm.
nnnnnnnnnnnnnnnnn. Metode moderne de analiză şi determinare a cerinţelor
sistemului
ooooooooooooooooo. -Joint Application Design(JAD)
ppppppppppppppppp. Spre sfârş itul anilor 1970, specialiş tii în realizarea de
sisteme de la IBM au elaborat un nou proces
qqqqqqqqqqqqqqqqq. de culegere a cerinţelor informaţionale ale sistemelor
ş i de revizuire a proiectelor sistemelor, numindu-se
rrrrrrrrrrrrrrrrr. JAD [1].
sssssssssssssssss. Ideea principală a lui JAD o constituie punerea laolaltă a
tuturor forţelor interesate în dezvoltarea
ttttttttttttttttt. sistemelor: utilizatori-cheie, managerii ş i analiş tii de sistem implicaţi
în analiza sistemului curent. Din
uuuuuuuuuuuuuuuuu. acest punct de vedere JAD este similar interviului la
nivel de grup. Totuş i în sesiunea JAD se urmă reş te o
vvvvvvvvvvvvvvvvv. anumită secvenţă de derulare a activită ţilor, pe baza unor
roluri bine stabilite.
wwwwwwwwwwwwwwwww. -Prototipizarea şi determinarea cerinţelor
sistemelor
xxxxxxxxxxxxxxxxx. Prototipizarea este un proces interactiv prin care analiş tii ş i
utilizatorii pun în discuţie o versiune
yyyyyyyyyyyyyyyyy. rudimentară a unui sistem informaţional, care va fi într-o
continuă schimbare, în funcţie de reacţia
zzzzzzzzzzzzzzzzz. utilizatorilor. Prototipizarea renunţă la ciclul de viaţă al
dezvoltă rii sistemelor sau la creş terea rolului să u
aaaaaaaaaaaaaaaaaa.[1].
bbbbbbbbbbbbbbbbbb. Pentru culegerea informaţiilor despre cerinţele
utilizatorilor încă se apelează la interviuri, dar prin
cccccccccccccccccc. prototipizare, operaţiunea va fi mai simplă ş i va solicita un
timp mai scurt. Prototipul este vă zut ş i testat de
dddddddddddddddddd. utilizator, având posibilitatea să precizeze ce ar mai
dori, dar ş i să -ş i genereze această formă nouă , cu
eeeeeeeeeeeeeeeeee. ajutorul specialiş tilor [1].
ffffffffffffffffff.
gggggggggggggggggg.
hhhhhhhhhhhhhhhhhh.
iiiiiiiiiiiiiiiiii.
jjjjjjjjjjjjjjjjjj. Teste rezolvate capitolul 4
kkkkkkkkkkkkkkkkkk. 1. Afirmaţiile următoare nu sunt corecte:
llllllllllllllllll. a) Fiecare Format/formular de intrare va fi asociat unui flux al datelor de
intrare într-un proces al DFD;
mmmmmmmmmmmmmmmmmm. b) Un proces al DFD va fi asociat cu o macheta de
ecran;
nnnnnnnnnnnnnnnnnn. c) Rapoartele se pot regăsi într-un flux al datelor generate de
un proces al DFD.
oooooooooooooooooo. Răspuns: b
pppppppppppppppppp.
qqqqqqqqqqqqqqqqqq. 2. Prezentarea informaţiile din formulare/formate şi rapoarte
pot fi oferite:
rrrrrrrrrrrrrrrrrr. a) sub formă de text;
ssssssssssssssssss. b) sub formă de sfaturi;
tttttttttttttttttt. c) sub formă de grafice;
uuuuuuuuuuuuuuuuuu. d) sub formă de tabele.
vvvvvvvvvvvvvvvvvv. Răspuns: a, c, d
wwwwwwwwwwwwwwwwww.
xxxxxxxxxxxxxxxxxx. 3. Macheta imprimantei cuprinde:
yyyyyyyyyyyyyyyyyy. a) antet;
zzzzzzzzzzzzzzzzzz. b) titlu;
aaaaaaaaaaaaaaaaaaa. c) date elementare ce se imprima rând de rând;
bbbbbbbbbbbbbbbbbbb. d) totalurile.
ccccccccccccccccccc. Răspuns: a, b, c, d
ddddddddddddddddddd.
eeeeeeeeeeeeeeeeeee. 4. Detaliile şi indicaţiile tehnice de realizare a machetei
imprimantei se referă la:
fffffffffffffffffff. a) volumul datelor de ieşire;
ggggggggggggggggggg. b) intensitatea datelor;
hhhhhhhhhhhhhhhhhhh. c) contrast.
iiiiiiiiiiiiiiiiiii. Răspuns: a
jjjjjjjjjjjjjjjjjjj.
kkkkkkkkkkkkkkkkkkk. 5. Alegerea tipului de suport fizic de ieşire (imprimanta, display, etc.)
se face în funcţie de:
lllllllllllllllllll. a) sursa de energie;
mmmmmmmmmmmmmmmmmmm. b) calitatea datelor;
nnnnnnnnnnnnnnnnnnn. c) costul suportului.
ooooooooooooooooooo. Răspuns: c
ppppppppppppppppppp.
qqqqqqqqqqqqqqqqqqq. 6. În definitivarea formei şi formatului de prezentare a
situaţiilor finale trebuie să ţinem seama de o serie
rrrrrrrrrrrrrrrrrrr. de considerente practice cum ar fi:
sssssssssssssssssss. a) Respectarea unor cerinţe ale factorilor de decizie privind macheta
situaţiei finale;
ttttttttttttttttttt. b) Restricţii tehnice;
uuuuuuuuuuuuuuuuuuu. c) Utilizarea formularelor pretipărite;
vvvvvvvvvvvvvvvvvvv. d) Utilizarea generatoarelor de rapoarte.
wwwwwwwwwwwwwwwwwww. Răspuns: a, b, c, d
xxxxxxxxxxxxxxxxxxx.
yyyyyyyyyyyyyyyyyyy. 7. Activităţile parcurse la realizarea unui sistem de coduri sunt:
zzzzzzzzzzzzzzzzzzz. a) analiza elementelor care urmează a fi codificate;
aaaaaaaaaaaaaaaaaaaa. b) analiza sistemului decizional;
bbbbbbbbbbbbbbbbbbbb. c) uniformizarea datelor de intrare;
cccccccccccccccccccc. d) alegerea tipurilor de coduri.
dddddddddddddddddddd. Răspuns: a, d
eeeeeeeeeeeeeeeeeeee.
ffffffffffffffffffff.8. La proiectarea intrărilor este necesar să se realizeze, în principal
următoarele activităţi:
gggggggggggggggggggg. a) alegerea colecţiilor de date;
hhhhhhhhhhhhhhhhhhhh. b) proiectarea machetelor documentelor de intrare;
iiiiiiiiiiiiiiiiiiii. c) alegerea regulilor de control şi validare a datelor;
jjjjjjjjjjjjjjjjjjjj. d) proiectarea formularelor (videoformatului) de intrare.
kkkkkkkkkkkkkkkkkkkk. Răspuns: b, c, d
llllllllllllllllllll.
mmmmmmmmmmmmmmmmmmmm. 9. Macheta documentului de intrare conţine:
nnnnnnnnnnnnnnnnnnnn. a) antetul documentului;
oooooooooooooooooooo. b) diagrama fluxului de date;
pppppppppppppppppppp. c) denumirea documentului.
qqqqqqqqqqqqqqqqqqqq. Răspuns: a, c
rrrrrrrrrrrrrrrrrrrr. 10. Nu sunt metode de interacţiune om – maşină:
ssssssssssssssssssss. a) interacţiunea permanentă,
tttttttttttttttttttt. b) interacţiunea prin meniuri,
uuuuuuuuuuuuuuuuuuuu. c) interacţiunea bazată pe obiecte icons,
vvvvvvvvvvvvvvvvvvvv. d) interacţiunea prin limbaj natural.
wwwwwwwwwwwwwwwwwwww. Răspuns: a
xxxxxxxxxxxxxxxxxxxx.
yyyyyyyyyyyyyyyyyyyy. 11. Echipamentele necesare interacţiunii cu sistemul sunt:
zzzzzzzzzzzzzzzzzzzz. a) eyescreen;
aaaaaaaaaaaaaaaaaaaaa. b) keyboard;
bbbbbbbbbbbbbbbbbbbbb. c) mouse.
ccccccccccccccccccccc. Răspuns: b, c
ddddddddddddddddddddd.
eeeeeeeeeeeeeeeeeeeee. 12. Construirea prototipului secvenţei de derulare a
dialogurilor se poate face cu ajutorul:
fffffffffffffffffffff. a) instrucţiunilor repetitive;
ggggggggggggggggggggg. b) produselor CASE;
hhhhhhhhhhhhhhhhhhhhh. c) mediile de dezvoltare grafică.
iiiiiiiiiiiiiiiiiiiii. Răspuns: b, c
jjjjjjjjjjjjjjjjjjjjj.
kkkkkkkkkkkkkkkkkkkkk. 13. În procesul de modelare logică a datelor sunt paşi
esenţiali:
lllllllllllllllllllll. a) Realizarea unui model logic al datelor din perspectiva utilizatorului
(formulare şi rapoarte) privind aplicaţia, folosindu-se principiile normalizări;
mmmmmmmmmmmmmmmmmmmmm. b) Implementarea modelului logic al datelor.
nnnnnnnnnnnnnnnnnnnnn. c) Transformarea modelului conceptual al datelor (entitate-
relaţie), realizat fără să se ţină cont de perspectiva utilizatorului, într-un set de relaţii
normalizate;
ooooooooooooooooooooo. Răspuns: a, c
ppppppppppppppppppppp.
qqqqqqqqqqqqqqqqqqqqq. 14. Nu sunt elemente de bază ale structurii relaţionale a
datelor:
rrrrrrrrrrrrrrrrrrrrr. a) Relaţia;
sssssssssssssssssssss. b) Atributul;
ttttttttttttttttttttt. c) Fişierul;
uuuuuuuuuuuuuuuuuuuuu. d) Domeniul;
vvvvvvvvvvvvvvvvvvvvv. e) Tuplul.
wwwwwwwwwwwwwwwwwwwww. Răspuns: c
xxxxxxxxxxxxxxxxxxxxx.
yyyyyyyyyyyyyyyyyyyyy. 15. Paşii parcurşi în procesul de transformare a diagramelor
entitate-relaţie în relaţii sunt:
zzzzzzzzzzzzzzzzzzzzz. a) Reprezentarea entităţilor;
aaaaaaaaaaaaaaaaaaaaaa. b) Reprezentarea legăturilor;
bbbbbbbbbbbbbbbbbbbbbb. c) Normalizarea relaţiilor.
cccccccccccccccccccccc. Răspuns: a, b, c
dddddddddddddddddddddd.
eeeeeeeeeeeeeeeeeeeeee. 16. Modelul conceptual pune în evidenţă:
ffffffffffffffffffffff. a) modul de stocare a datelor pe suportul de memorare;
gggggggggggggggggggggg. b) reprezentarea logică, detaliată a entităţilor, asocierilor
(legăturilor) şi datelor elementare ale unei organizaţii;
hhhhhhhhhhhhhhhhhhhhhh. c) structura globală de organizare a datelor.
iiiiiiiiiiiiiiiiiiiiii. Răspuns: b), c)
jjjjjjjjjjjjjjjjjjjjjj.
kkkkkkkkkkkkkkkkkkkkkk. 17. Normalizarea unei relaţii constă în:
llllllllllllllllllllll. a) Descrierea relaţiei în limbajul de descriere a datelor;
mmmmmmmmmmmmmmmmmmmmmm. b) Identificarea dependenţelor între
atributele relaţiei;
nnnnnnnnnnnnnnnnnnnnnn. c) Descompunerea relaţiei în relaţii echivalente urmărind
eliminarea redundanţei datelor şi anomaliilor la efectuarea operaţiilor de adaugare,
actualizare şi ştergere în baza de date.
oooooooooooooooooooooo. Răspuns: c)
pppppppppppppppppppppp.
qqqqqqqqqqqqqqqqqqqqqq. Teste rezolvate capitolul 5
rrrrrrrrrrrrrrrrrrrrrr. 1. Proiectarea fizică a sistemelor informatice înseamnă:
ssssssssssssssssssssss. a) o abordare detaliată a sistemului;
tttttttttttttttttttttt. b) o abordare de ansamblu a sistemului
uuuuuuuuuuuuuuuuuuuuuu. c) o abordare generală a sistemului;
vvvvvvvvvvvvvvvvvvvvvv. Răspuns : a
wwwwwwwwwwwwwwwwwwwwww.
xxxxxxxxxxxxxxxxxxxxxx. 2. Proiectarea fizică a sistemelor informatice implică:
yyyyyyyyyyyyyyyyyyyyyy. a) proiectarea fizică a bazelor de date şi a fişierelor.
zzzzzzzzzzzzzzzzzzzzzz. b) proiectarea structurii sistemului şi a programelor.
aaaaaaaaaaaaaaaaaaaaaaa. c) proiectarea documentaţiei sistemului analizat.
bbbbbbbbbbbbbbbbbbbbbbb. d) proiectarea strategiilor de prelucrare distribuită.
ccccccccccccccccccccccc. Răspuns : a, b, d
ddddddddddddddddddddddd.
eeeeeeeeeeeeeeeeeeeeeee. 3. Proiectarea fizică a bazelor de date şi a fişierelor îşi
propune să asigure:
fffffffffffffffffffffff. a) trecerea de la descrierea logică a datelor la una tehnică, de stocare
a datelor;
ggggggggggggggggggggggg. b) structura globală de organizare a datelor;
hhhhhhhhhhhhhhhhhhhhhhh. c) descrierea logică a datelor.
iiiiiiiiiiiiiiiiiiiiiii. Răspuns : a
jjjjjjjjjjjjjjjjjjjjjjj.
kkkkkkkkkkkkkkkkkkkkkkk. 4. Sunt structuri de control fundamentale în realizarea
programelor:
lllllllllllllllllllllll. a) structura secvenţială;
mmmmmmmmmmmmmmmmmmmmmmm. b) structură funcţională;
nnnnnnnnnnnnnnnnnnnnnnn. c) structura alternativă;
ooooooooooooooooooooooo. d) structura organizaţională:
ppppppppppppppppppppppp. e) structura repetitivă.
qqqqqqqqqqqqqqqqqqqqqqq. Răspuns : a, c, e
rrrrrrrrrrrrrrrrrrrrrrr.
sssssssssssssssssssssss. 5. Structura repetitivă condiţionată anterior este:
ttttttttttttttttttttttt. a) de tip WHILE-DO;
uuuuuuuuuuuuuuuuuuuuuuu. b) de tip DO UNTIL;
vvvvvvvvvvvvvvvvvvvvvvv. c) de tip DO FOR.
wwwwwwwwwwwwwwwwwwwwwww. Răspuns : a
xxxxxxxxxxxxxxxxxxxxxxx.
yyyyyyyyyyyyyyyyyyyyyyy. 6. Nu sunt metode de programare:
zzzzzzzzzzzzzzzzzzzzzzz. a) metoda programării clasice;
aaaaaaaaaaaaaaaaaaaaaaaa. b) metoda programării structurate;
bbbbbbbbbbbbbbbbbbbbbbbb. c) metoda programării orientate-obiect;
cccccccccccccccccccccccc. d) metoda programării iterative.
dddddddddddddddddddddddd. Răspuns : d
eeeeeeeeeeeeeeeeeeeeeeee.
ffffffffffffffffffffffff. 7. Un modul are componente de bază:
gggggggggggggggggggggggg. a) funcţia;
hhhhhhhhhhhhhhhhhhhhhhhh. b) schema;
iiiiiiiiiiiiiiiiiiiiiiii. c) logica;
jjjjjjjjjjjjjjjjjjjjjjjj. d) interfeţele.
kkkkkkkkkkkkkkkkkkkkkkkk. Răspuns : a, c, d
llllllllllllllllllllllll.
mmmmmmmmmmmmmmmmmmmmmmmm. 8. Funcţia unui modul constă în:
nnnnnnnnnnnnnnnnnnnnnnnn. a) transformarea datelor prin procesul de execuţie a
acestuia.
oooooooooooooooooooooooo. b) descrierea prelucrărilor care au loc în interiorul
acestuia.
pppppppppppppppppppppppp. c) legătura cu alte module.
qqqqqqqqqqqqqqqqqqqqqqqq. Răspuns : a
rrrrrrrrrrrrrrrrrrrrrrrr.
ssssssssssssssssssssssss. 9. Realizarea modulară a programelor corespunde
principiilor:
tttttttttttttttttttttttt. a) programării clasice;
uuuuuuuuuuuuuuuuuuuuuuuu. b) programării structurate;
vvvvvvvvvvvvvvvvvvvvvvvv. c) bazelor de cunoştinţe;
wwwwwwwwwwwwwwwwwwwwwwww. Răspuns : b
xxxxxxxxxxxxxxxxxxxxxxxx.
yyyyyyyyyyyyyyyyyyyyyyyy. 10. Principalele module de proiectare a sistemelor de
prelucrare distribuită a datelor sunt:
zzzzzzzzzzzzzzzzzzzzzzzz. a) proiectarea nodurilor;
aaaaaaaaaaaaaaaaaaaaaaaaa. b) proiectarea diagramelor;
bbbbbbbbbbbbbbbbbbbbbbbbb. c) proiectarea reţelei de comunicaţii.
ccccccccccccccccccccccccc. Răspuns : a, c
ddddddddddddddddddddddddd.
eeeeeeeeeeeeeeeeeeeeeeeee. 11. Nu sunt componente de bază ale tehnologiei
client/server:
fffffffffffffffffffffffff. a) clientul;
ggggggggggggggggggggggggg. b) administratorul de sistem;
hhhhhhhhhhhhhhhhhhhhhhhhh. c) serverul;
iiiiiiiiiiiiiiiiiiiiiiiii. d) reţeaua care conectează clientul la server.
jjjjjjjjjjjjjjjjjjjjjjjjj. Răspuns : b
kkkkkkkkkkkkkkkkkkkkkkkkk.
lllllllllllllllllllllllll. 12. Care dintre următoarele instrucţiuni nu sunt decizionale ?
mmmmmmmmmmmmmmmmmmmmmmmmm. a) WHILE ... WEND ;
nnnnnnnnnnnnnnnnnnnnnnnnn. b) IF...END IF;
ooooooooooooooooooooooooo. c) IF...ELSE...END IF;
ppppppppppppppppppppppppp. d) IF...THEN...ELSE IF... ... ...END IF ;
qqqqqqqqqqqqqqqqqqqqqqqqq. e) SELECT CASE...CASE... ... ...END SELECT.
rrrrrrrrrrrrrrrrrrrrrrrrr. Răspuns : a
sssssssssssssssssssssssss.
ttttttttttttttttttttttttt. 13. Care dintre următoarele instrucţiuni repetitive sunt condiţionate
posterior ?
uuuuuuuuuuuuuuuuuuuuuuuuu. a) FOR...NEXT ;
vvvvvvvvvvvvvvvvvvvvvvvvv. b) WHILE...WEND ;
wwwwwwwwwwwwwwwwwwwwwwwww. c) DO WHILE...LOOP;
xxxxxxxxxxxxxxxxxxxxxxxxx. d) DO UNTIL...LOOP;
yyyyyyyyyyyyyyyyyyyyyyyyy. e) DO...LOOP WHILE.
zzzzzzzzzzzzzzzzzzzzzzzzz. Răspuns : e
aaaaaaaaaaaaaaaaaaaaaaaaaa.
bbbbbbbbbbbbbbbbbbbbbbbbbb. 14. Proiectarea fizică a bazei de date are în vedere:
cccccccccccccccccccccccccc. a) modul de stocare a datelor pe suportul de memorare;
dddddddddddddddddddddddddd. b) trecerea de la descrierea logică a datelor la una
tehnică, de stocare a datelor;
eeeeeeeeeeeeeeeeeeeeeeeeee. b) structura globală de organizare a datelor.
ffffffffffffffffffffffffff. Răspuns: a), b)
gggggggggggggggggggggggggg.
hhhhhhhhhhhhhhhhhhhhhhhhhh. 15. Sistemul de Gestiune a Bazelor de Date este:
iiiiiiiiiiiiiiiiiiiiiiiiii. a) un sistem de programe care permite definirea, crearea şi întreţinerea bazei
de date precum şi
jjjjjjjjjjjjjjjjjjjjjjjjjj. accesul controlat la baza de date;
kkkkkkkkkkkkkkkkkkkkkkkkkk. b) un sistem de programe pentru interogarea bazei de date.
llllllllllllllllllllllllll. Răspuns: a)
mmmmmmmmmmmmmmmmmmmmmmmmmm.
nnnnnnnnnnnnnnnnnnnnnnnnnn. Întrebări şi răspunsuri
oooooooooooooooooooooooooo. 1. Enumeraţi arhitecturile de bază pentru un sistem
client-server după rolul pecare îl au
pppppppppppppppppppppppppp. componentele client şi server;
qqqqqqqqqqqqqqqqqqqqqqqqqq. Răspuns:
rrrrrrrrrrrrrrrrrrrrrrrrrr. - arhitectura de tip server de obiecte;
ssssssssssssssssssssssssss. - arhitectura de tip server de pagini;
tttttttttttttttttttttttttt. - arhitectura de tip server de bază de date.
uuuuuuuuuuuuuuuuuuuuuuuuuu.
vvvvvvvvvvvvvvvvvvvvvvvvvv. 2. Enumeraţi cele 3 nivele ale noii arhitecturi client-server
definite ca urmare a utilizării a unor platforme hard-soft
wwwwwwwwwwwwwwwwwwwwwwwwww. diferite, precum şi integrării bazelor de date
în mediul Web:
xxxxxxxxxxxxxxxxxxxxxxxxxx. Răspuns:
yyyyyyyyyyyyyyyyyyyyyyyyyy. - nivelul client, la care se realizează interfaţa cu utilizatorul
aplicaţiei;
zzzzzzzzzzzzzzzzzzzzzzzzzz. - nivelul server de aplicaţie, la care se realizează logica
aplicaţiei şi prelucrării datelor;
aaaaaaaaaaaaaaaaaaaaaaaaaaa. - nivelul server de baze de date, la care se realizează
validarea datelor şi accesul la baza de date.
bbbbbbbbbbbbbbbbbbbbbbbbbbb.
ccccccccccccccccccccccccccc.
ddddddddddddddddddddddddddd.
eeeeeeeeeeeeeeeeeeeeeeeeeee.
fffffffffffffffffffffffffff.
ggggggggggggggggggggggggggg. ADENDA
hhhhhhhhhhhhhhhhhhhhhhhhhhh. Sistem - un ansamblu de elemente (componente)
interdependente între care se stabileşte o
iiiiiiiiiiiiiiiiiiiiiiiiiii. interacţiune dinamică, pe baza unor reguli prestabilite, cu scopul
atingerii unui anumit obiectiv.
jjjjjjjjjjjjjjjjjjjjjjjjjjj. Sistem informaţional - ansamblul informaţiilor interne şi externe
utilizate în cadrul organizaţiei precum şi datele care au stat la baza obţinerii lor,
procedurile şi tehnicile de obţinere a informaţiilor (plecând de la datele primare) şi de
difuzare a informaţiilor, precum şi personalul implicat în culegerea, transmiterea,
stocarea şi prelucrarea datelor.
kkkkkkkkkkkkkkkkkkkkkkkkkkk. Sistem informatic - un sistem utilizator-calculator integrat,
care furnizează informaţii pentru a sprijini activităţile de la nivel operaţional şi activităţile
de management într-o organizaţie, utilizând echipamente hardware şi produse software,
proceduri manuale, o bază de date şi modele matematice pentru analiză, planificare,
control şi luarea deciziilor.
lllllllllllllllllllllllllll. Sistem informatic de gestiune - sistem integrat caracterizat printr-o
introducere unică a datelor, preluate din documentele primare care actualizează o bază
de date unică a contabilităţii care va fi ulterior prelucrată pentru obţinerea situaţiilor
specifice fiecărui utilizator folosind mijloacele tehnologiei informaţiei (TI).
mmmmmmmmmmmmmmmmmmmmmmmmmmm. Ciclul de viaţă a unui sistem
informatic – etapele de parcurs începând cu decizia realizării unui nou SI care să
corespundă mai bine noilor cerinţe ale utilizatorilor şi terminând cu decizia de înlocuire a
SI existent cu unul nou, mai performant.Fişierul – este o organizare a datelor preluată din
sistemul manual şi adaptată la cerinţele impuse de utilizarea sistemelor de calcul.
nnnnnnnnnnnnnnnnnnnnnnnnnnn. Ciclul prelucrării datelor pentru sistemul informatic -
operaţiunile care se execută asupra
ooooooooooooooooooooooooooo. datelor, din momentul apariţiei lor, pentru a genera
informaţii semnificative şi relevante
ppppppppppppppppppppppppppp. Metodologie - ordonarea unui proces complex, într-o
succesiune bine stabilită de etape şi
qqqqqqqqqqqqqqqqqqqqqqqqqqq. subetape şi utilizarea unor metode şi tehnici
adecvate.
rrrrrrrrrrrrrrrrrrrrrrrrrrr. Metodele utilizate în proiectarea sistemelor informatice -
modul unitar sau maniera comună în care analiştii de sisteme, programatorii şi alte
categorii de persoane implicate, realizează procesul de analiză a sistemului
informaţional-decizional existent, proiectarea şi introducerea sistemului informatic.
sssssssssssssssssssssssssss. Tehnicile de lucru utilizate în proiectarea sistemelor
informatice - reprezintă felul în care se acţionează eficient şi rapid, în cadrul unei
metode, pentru soluţionarea diferitelor probleme ce apar în procesul de proiectare.
ttttttttttttttttttttttttttt. Microanaliza - identificarea şi selecţia proiectelor de dezvoltare a
sistemelor informaţionale
uuuuuuuuuuuuuuuuuuuuuuuuuuu. împreună cu iniţierea şi planificarea proiectelor.
vvvvvvvvvvvvvvvvvvvvvvvvvvv. Studiu de fezabilitate - informaţiile obiective necesare
pentru a cunoaşte dacă un proiect poate fi demarat sau nu, sau dacă un proiect deja
început mai poate fi continuat.
wwwwwwwwwwwwwwwwwwwwwwwwwww. Diagrama Gantt - o modalitate de
reprezentare grafică care permite urmărirea planificării şi
xxxxxxxxxxxxxxxxxxxxxxxxxxx. realizării proiectului.
yyyyyyyyyyyyyyyyyyyyyyyyyyy. Sistem existent - realitatea obiectivă din organizaţia pentru
care urmează a se realiza sistemul
zzzzzzzzzzzzzzzzzzzzzzzzzzz. informatic solicitat printr-o comandă numită cererea
beneficiarului.
aaaaaaaaaaaaaaaaaaaaaaaaaaaa. Joint Application Design(JAD) – un proces de
culegere a cerinţelor informaţionale ale
bbbbbbbbbbbbbbbbbbbbbbbbbbbb. sistemelor şi de revizuire a proiectelor sistemelor,
prin care se realizează punerea laolaltă a tuturor forţelor interesate în dezvoltarea
sistemelor: utilizatori-cheie, managerii şi analiştii de sistem implicaţi în analiza sistemului
curent.
cccccccccccccccccccccccccccc. Prototipizarea - un proces interactiv prin care analiştii şi
utilizatorii pun în discuţie o versiune rudimentară a unui sistem informaţional, care va fi
într-o continuă schimbare, în funcţie de reacţia utilizatorilor.
dddddddddddddddddddddddddddd. Diagrama fluxului de date DFD- o tehnică de analiză
structurată prin care se realizează reprezentarea circuitului datelor, structurii lor şi
cerinţelor funcţionale ale noului sistem, urmărind modul de transfer al datelor între
procesele deprelucrare a lor;
eeeeeeeeeeeeeeeeeeeeeeeeeeee. - o reprezentare grafică a transformării datelor de
intrare în date de ieşire
ffffffffffffffffffffffffffff. folosind un set de simboluri de reprezentare şi un set de reguli de
completare şi validare.
gggggggggggggggggggggggggggg. Relaţie pe mulţimile D1, D2, …., Dn este o mulţime de
tuple ordonate, o submulţime a
hhhhhhhhhhhhhhhhhhhhhhhhhhhh. produsului cartezian D1xD2x….xDn.
iiiiiiiiiiiiiiiiiiiiiiiiiiii. Cheie a unei relaţii R este un subset minimal K de atribute ale relaţiei
care identifică unic ntuplele relaţiei.
jjjjjjjjjjjjjjjjjjjjjjjjjjjj. Obiect este o entitate unic identificabilă, care conţine atât atributele
care descriu starea unui
kkkkkkkkkkkkkkkkkkkkkkkkkkkk. obiect din lumea reală, cât şi acţiunile asociate
acestuia.
llllllllllllllllllllllllllll. Atribut este o proprietate sau o caracteristică a unei entităţi care
prezintă interes pentru
mmmmmmmmmmmmmmmmmmmmmmmmmmmm. organizaţie.
nnnnnnnnnnnnnnnnnnnnnnnnnnnn. Diagrama Entitate-Relaţie DER – o formă grafică de
reprezentare a modelului conceptual al
oooooooooooooooooooooooooooo. datelor prin care se prezintă caracteristicile şi
structura datelor independent de modul în care acestea sunt memorate în calculator.
pppppppppppppppppppppppppppp. Sistemele CASE sunt produse complexe care permit
ca procesele de proiectare şi realizare a
qqqqqqqqqqqqqqqqqqqqqqqqqqqq. aplicaţiilor să se desfăşoare într-un mediu informatic
interactiv, oferind utilizatorilor un întreg arsenal de instrumente şi proceduri, prin care
pot proiecta, realiza, testa, documenta, întreţine/actualiza şi exploata sistemul
informatic.
rrrrrrrrrrrrrrrrrrrrrrrrrrrr. Baza de date – o colecţie partajată de date, care conţine
datele propriu-zise, relaţiile logice dintre acestea, precum şi descrierea datelor (structura
datelor).
ssssssssssssssssssssssssssss. Sistemul de Gestiune a Bazelor de Date (SGBD sau DBMS
Data Base Management
tttttttttttttttttttttttttttt. System) – este un sistem de programe care permite definirea,
crearea şi întreţinerea bazei de date, precum şi accesul controlat la baza de date.
uuuuuuuuuuuuuuuuuuuuuuuuuuuu. Administratorul bazei de date (DBA – Data Base
Administrator) - este o persoană sau un grup de persoane care răspunde de ansamblul
activităţilor privind baza de date.
vvvvvvvvvvvvvvvvvvvvvvvvvvvv. Model de date este un instrument teoretic care
permite identificarea semnificaţiei sau conţinutului de informaţie pentru o colecţie de
date, văzută în ansamblul ei, prin contrast cu valorile individuale ale datelor.
wwwwwwwwwwwwwwwwwwwwwwwwwwww. Model conceptual - structura globală
de organizare a datelor, asigurându-se independenţa totală faţă de orice sistem de
gestiune a bazelor de date. 99].
xxxxxxxxxxxxxxxxxxxxxxxxxxxx. Modelul logic al datelor - descrierea datelor în concordanţă
cu modelul de organizare a acestora de către sistemele de gestiune a bazelor de date.
yyyyyyyyyyyyyyyyyyyyyyyyyyyy. Proiectarea fizică a bazelor de date şi a fişierelor -
trecerea de la descrierea logică a datelor la una tehnică, de stocare a datelor.
zzzzzzzzzzzzzzzzzzzzzzzzzzzz. ACCESS produs program pentru gestiunea bazelor de date
relaţionale de complexitate medie
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaa. SQL limbaj universal pentru bazele de date
relaţionale.
bbbbbbbbbbbbbbbbbbbbbbbbbbbbb. Tabele – stochează datele bazei de date. Fiecare
coloană a tabelei este numită câmp şi fiecare rând al tabelei este numit înregistrare.
ccccccccccccccccccccccccccccc. Interogări (Queries) – realizează extragerea unor date din
una sau mai multe tabele conform
ddddddddddddddddddddddddddddd. unor criterii precizate de utilizator în vederea
vizualizării şi actualizării datelor din baza de date sau pentru a crea alte tabele în vederea
păstrării unui instantaneu al informaţiilor.
eeeeeeeeeeeeeeeeeeeeeeeeeeeee. Formulare – un formular este o fereastră pentru
introducerea sau afişarea şi editarea datelor. Un formular poate conţine subformulare
pentru a afişa date asociate unor date din formular şi butoane sau alte obiecte grafice
pentru realizarea anumitor acţiuni.
fffffffffffffffffffffffffffff.
ggggggggggggggggggggggggggggg. Rapoarte – sunt utilizate pentru operaţii de ieşire în
vederea obţinerii unor situaţii rezultate din prelucrarea unor date din baza de date.
hhhhhhhhhhhhhhhhhhhhhhhhhhhhh. Vedere este o relaţie virtuală, definită plecând de la
alte relaţii din baza de date şi care nu conţine date şi deci nu ocupă spaţiu fizic pe disc.
iiiiiiiiiiiiiiiiiiiiiiiiiiiii.
jjjjjjjjjjjjjjjjjjjjjjjjjjjjj.
kkkkkkkkkkkkkkkkkkkkkkkkkkkkk.
lllllllllllllllllllllllllllll.
mmmmmmmmmmmmmmmmmmmmmmmmmmmmm.
nnnnnnnnnnnnnnnnnnnnnnnnnnnnn.
ooooooooooooooooooooooooooooo.
ppppppppppppppppppppppppppppp.
qqqqqqqqqqqqqqqqqqqqqqqqqqqqq.
rrrrrrrrrrrrrrrrrrrrrrrrrrrrr.
sssssssssssssssssssssssssssss.
ttttttttttttttttttttttttttttt.
uuuuuuuuuuuuuuuuuuuuuuuuuuuuu.
vvvvvvvvvvvvvvvvvvvvvvvvvvvvv.
wwwwwwwwwwwwwwwwwwwwwwwwwwwww.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
yyyyyyyyyyyyyyyyyyyyyyyyyyyyy.
zzzzzzzzzzzzzzzzzzzzzzzzzzzzz.
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.
cccccccccccccccccccccccccccccc.
dddddddddddddddddddddddddddddd.
eeeeeeeeeeeeeeeeeeeeeeeeeeeeee.
ffffffffffffffffffffffffffffff.
gggggggggggggggggggggggggggggg.
hhhhhhhhhhhhhhhhhhhhhhhhhhhhhh.

Subiect nr2.
1.Instrumentele CASE:

a. se bazeaza pe definirea specificatiilor pe support de hartie

b. urmareste cresterea complexitatii procesului de proiectare a unui SI

c. ofera support proiectantului in realizarea unui produs informatic

d. sunt folosite pentru stoarea, prelucrarea si generarea informatiilor necesare pentru gestiunea
activitatilor si pentru fundamentarea deciziilor

2.Diagrama de secvente:

a. modeleaza aspect statice ale sistemului

b. cuprinde stari, tranzitii si noduri

c. are rol de a valida diagrame de clase

d. subliniaza ordinea mesajelor schimbate intre obiecte in functie de timp

3.Ciclul de viata al unui sistem informatic:

a. este cuprins in ciclul de dezvoltare al sistemului informtic

b. este un sablon pentru ordonarea activitatilor de realizare a sistemului informatics

c. poate fi organizat in 5 etape(identificarea cerintelor, analiza,proiectare,implementare,

mentenanta)

d. se incheie cu decizia de abandonare a sistemului si inlocuirea lui cu un system nou

Slectati variant corecta:

5. a+c+d
6. a+b
7. b+c+d
8. c+d

4.Este specific unei stari intr-o diagram UML:

a. este inclusa in diagram de clase

b. poate include actiuni special

c. este inclusa in diagram de activitate

d. descrie un flux de lucru

5.Acele limbaje pentru modelarea informational care au reguli stricte, iar sintaxa si semantic sunt
definite matematic, se numesc:

a. limbaje formale

b. limbaje informationale

c. limbaje semi-formale

d.limbaje de programare

6.Printre elementele de baza ale limbajului UML nu se numara:

a. meta-model pentru modelarea orientate obiect

b. procese de dezvoltare

c.diagrame

d. mecanisme de extensie

7.Agregarea partial are urmatoarele caracteristici:

a. este o forma puternica de agregare

b. se reprezinta sub forma unui romb plin

c. este o forma slaba de agregare

d. reprezinta o relatie de tip parinte-copil

8. In limbajul BPMN, portile paralele:

a. sunt cunoscute sub denumirea de decizii

b. arata ca numai una din caile de iesire va fi urmata

c. verifica o conditie care sa duca la declansarea iesirilor

d. nu verifica nicio conditie care sa duca la declansarea iesirilor

9.Cu ajutorul diagramelor UML, nu se poate realize:

a. modelarea proceselor de afaceri

b. modelarea structurii statice

c. modelarea componentelor echipelor de lucru din organizatie

d.modelarea structurii dinamice

10.Cerintele care defines functiile unui SI sau ale componentelor acestuia se numesc:

a. cerinte functionale

b. cerinte arhitecturale

c. cerinte de calitate

d. cerinte de dezvoltare

11. SI are urmatoarele caracteristici:

a. este inclus in cadrul sistemului informational decizional

b. se ocupa de culegerea, stocarea si prelucrarea automata a datelor

c. include sistemul informational decizional

d. are rolul de a asista sau participa la procesul decizional

Varianta corecta:

1.a,b,c

2.c,d

3.a,b,d

4.a,c,d

12. In limbajul BPMN, un eveniment:

a. reprezinta un obiect de conectare

b. afecteaza fluxul unui model

c. este atomic sau non-atomic

d. poate fi inclusiv sau exclusive

13. O metodologie de realizare a unui sistem informatic trebuie sa cuprinda:

a. detalii privind tehnologii de implementare a SI

b. limbajele de programare utilizate

c. modalitatea de derulare a ciclului de viata al sistemului infomatic

d. instrumente specific de scriere de cod sursa

14. Printre somponentele unui SI nu se afla:

a. sistemul informational

b. comunicatiile

c. software

d. utilizatorii

15. Diagrama de stare UML:

a. modeleaza aspect statice ale unei clase

b. modeleaza scvente de actiuni

c. modeleaza starea functional a unui obiect

d. include stari si tranzitii

16. Metodologiile extreme programming(XP) si SCRUM se incadreaza in categoria metodologiilor:

a. cu abordare orientate obiect

b. cu abordare structural

c. bazate pe dezvoltare agila

d. bazate pe dezvoltare rapida(RAD)

17. Printre conceptele utilizate in realizarea SI se numara:

a. process/etapa

b. activitae
c. ciclul de dezvoltare al sistemului

d. toate cele de mai sus

18. Reprezinta caracteristici ale diagramei de cazuri de utilizare:

a. descrie o multime de clase

b. include cazuri de utilizare, actori, clase si stari

c. descrie fluxul de activitati

d. produce un rezultat important pentru un actor

19. Printre tarsaturile carcateristice ale modelarii, nu se numara:

a. simplificrea

b. subordonarea la un scop

c. reprezentarea unui decident, a unei situatii care nu exista in realitate inca

d. divizarea si ierarhizarea

20. Intr-un nod decizional din diagram de activitate:

a. fluxurile de iesire au conditii mutual exclusive

b. intra mai multe fluxuri si iese unul singur

c. intra mai multe fluxuri si ies mai multe fluxuri

d. se poate simula structura de control do-until de programare

Subiect nr4.
26. Video-formatul are ca si caracteristici:
f. Este o colectie de obiecte si rutine care defines interfetele aplicatiei
g. Contine obiecte ce raspund la interactiuniunuile utilizatorului
h. Contine obiecte ce raspund la evenimentele din system
 i. Cu ajutorul sau se pot insera sau sterge inregistrari in bd
j. Permite afisarea datelor din baza de date

Combinatia corecta:

e. B,c,d
f. A,b
g. A,b,c
h. A,b,c,d,e

27. Construirea sistemului informatic presupune:

e. Identificarea cerintelor SI
f. Analiza si proiectarea cerintelor sistemului
g. Analiza si tetarea programului
h. Conducerea procesului de dezvoltare

28. Mentenanta preventiva a datelor:

e. Implica inlaturarea defectelor sau erorilor de proiectare
f. Are rolul de a spori functionalitatea sistemului
g. Implementeaza noi cerinte ale sistemului
h. Reduce sau inlatura riscul caderii sistemului

29. Baza informationala din cadrul unui sistem informatic include:

e. Programul cu ajutorul carora functioneaza sistemul
f. Datele supuse prelucrarii
g. Regulamentul de organizare si functionare
h. Echipamente si tehnologii de comunicatie

30. O metodologie a unui SI nu trebuie sa cuprinda:

e. Etapele de realizare a sistemului
f. Strategia de normalizare a bazei de date
g. Modalitatea de derulare a ciclului de viata
h. Modalitatile de conducere a proiectului

31. Ciclul de dezvoltare a unui SI:

f. Include ciclul de viata
g. Este inclus in ciclul de viata
h. Cuprinde etape de analiza
i. Cuprinde etape de mentenanta
 j. Nu cuprinde etapa de proiectare

Combinatia corecta:

e. B,c
f. A,b,c
g. B,d,e
h. A,c,d,e

32. In limbajul BPMN, potile inclusive:

e. Pot declansa un singur rezultat
f. Nu evalueza conditii
g. Pot declansa mai mult de un rezultat
h. Au conditii numai exclusive

33. Diagrama de secventa:

f. Modeleaza aspecte statice ale sistemului
g. Este o diagrama de interactiune
h. Poate reprezenta logica procedurala
i. Include mesaje de tip apel
j. Include tranzitii intre starile obiectului

Combinatia corecta:

e. B,c,d
f. B,c,d,e
g. A,b,c
h. B,d,e

34. In BPMN, etapa de optimizare presupune:

e. Identificarea structurii organizationale si a interactiuniunilor umane
f. Identificarea pasilor care genereaza erori, intarzieri sau blocaje
g. Stabilirea indicatorilor de performanta
h. Identificarea subproceselor si obiectivelor

35. Elasticitatea este o cerinta impusa codurilor care sa permita:

e. Prelucrarea automata a datelor
f. Realizarea cu usurinta a operatiilor de codificare
g. Sugerarea caracteristicilor codificate
h. Inserari si extensii ale nomenclatorului de coduri
36. La proiectarea arhitecturii sistemului informatic, se identifica:
e. Tipul bazei de date si al fisierelor
f. Tipul tehnologiei informatice utilizate
g. Tipul retelei si al protocolului de comunicatii
h. Tipul metodologiei de dezvoltare folosite

37. Fluxul de mesaj in limbajul BPMN:

e. Descrie ordinea elementelor din flux
f. Arata fluxul de informatii din proces
g. Arata fluxul de mesaje intre 2 participanti
h. Traverseaza culoarul unei con…

38. Obiectele de flux in limbajul BPMN include:

e. Flux de secventa, flux de mesaj
f. Flux de secventa, flux de mesaj, asociere
g. Evenimentul, activitate, poarta
h. Container, culoar

39. Metodologiile bazate pe dezvoltarea agila au ca dezavantaj:

e. Sunt potrivite pentru mediile care se schimba
f. Nu ofera flexibilitate
g. Ofera documentatie suficenta
h. Depind mult de interactiunea cu beneficiarul

40. Editoarele de diagrame dintr-un instrument CASE permit:

e. Stocarea obiectelor proiectului
f. Generarea de cod
g. Reprezentarea vizuala a unui sistem
h. Crearea de prototipuri, de forme si rapoarte

41. Reprezinte un exemplu de specificatie prescriptiva:

e. Un client fidel va beneficia de o reducere de 20%
f. Daca un produs ne e pe stoc, atunci nu poate fi livrat
g. Daca stocul scade sub 10% atunci se solicita reaprovizionarea
h. Se livreaza gratuit comenzile de minim 200 RON
42. Reprezinta tehnici pentru identificarea cerintelor:
e. Interviurile, observatiile si analizele sociale
f. Analiza, proiectarea, testarea
g. Activitatile, datele, procesele
h. Cazurile de utilizare, clasele, starile

43. Intre cazurile de utilizare pot exista relatii de:

e. Asociere, extindere, generalizare
f. Asocoere, agregare, calificare
g. Includere, extindere, generalizare
h. Asociere, agregare, compunere

44. Cerintele non-functionale ale unui sistem informatic:

e. Contin informatii privind procesarea si manipularea datelor
f. Include calcule
g. Analizeaza operationalitatea sistemului
h. Analizeaza datele sistemului

45. Limbajele semi-formale sunt cele pentru care pot fi verificabile:

e. Regulile de sintaxa si semantica
f. Regulile de sintaxa, dar nu si de semantica
g. Regulile de semantica, dar nu si de sintaxa
h. Doar regulile de semantica

46. Metamodelul UML defineste concepte precum:

e. Tabela, tuplu, element
f. Client, produs, factura
g. Clasa, atribut, componenta
h. Integer,real,boolean

47. Relatia de sociere intre clase este caracterizata prin:

e. Denumire, tip, numar, stari
f. Denumire, atribute, stari, roluri
g. Denumire, multiplicitati, roluri, directie de navigare
h. Denumire,operatii,caracteristici,roluri
 48. Agregarea compusa este:
e. O forma slaba de agregare
f. O forma de dependenta
g. O forma de asociere binara
h. O forma de generalizare

49. Multiplicitatea la nivelul unui atribut al clasei descrie:

e. Cate instante poate avea clasa
f. Daca atributul este read-only
g. Cate valori poate lua un atribut
h. Daca atributul are o valoare implicita

50. Instrumentele de tip CASE:

f. Pun accentul doar pe codificare si testare
g. Pun accentul pe analiza si proiectare
h. Permit realizarea unei documentatii de calitate
i. Reduc timpul si costul de dezvoltare
j. Include editoare pentru diagrame

Combinatia corecta:

e. B,c,d
f. B,c,d,e
g. A,b,c,
h. A,d,e

Subiect nr1.

8. Diagramele de activitate:
e. Contin o descriere a vietii obiectelor unei clase
 f. Reprezinta comportamentul intern al unui caz de utilizare
g. Descrie interactiuniunile dintre diverse obiecte ale unui sistem =>
diadrama de obiecte
h. Pot fi folosite pentru a descrie procesare paralela

9. Ciclul de dezvoltare al unui sistem informatic cuprinde:

e. Intervalul de timp cuprins intre proiectarea si mentenanta sistemului
f. Intervalul de timp de la luarea deciziei de elaborare a unui sistem
informatic si pana la luarea deciziei de inlocuire a lui cu un alt sistem
informatic
g. Intervalul de timp de la luarea deciziei de realizare a unui sistem
pana la introducerea sistemului in exploatare
h. Doar etapele de analiza si proiectare

10.Urmatoarele diagrame nu folosesc pentru reprezentarea lor obiecte ale

claselor:
e. Diagramele de desfasurare
f. Diagramele de secventa
g. Diagramele de clase
h. Diagramele de obiecte

11.Care din urmatoarele varinate constiruie cerinte impuse codurilor:

e. Unitate, stratificare
f. Stabilitate, elasticitate
g. Portabilitate, comunicare
h. Conciziune,operationalitatea

12. Identificati variantele care sunt caracteristice sistemelor informatice

pentru managementul tactic:
e. Ajuta decidentul in activitatea sa
f. Utilizeaza baze de cunostiinte si modele
 g. Furnizeaza informatii conducerii executive
h. Folosesc abordarea sistematica pentru rezolvarea problemelor

13.Arhitectura orientata pe model:

e. Descrie modele independente si dependente de platforma
f. Propune cinci viziuni asupra unui sistem informatic
g. Are la baza transformari ale modelelor
h. Solicita construira unor modele UML cat mai complete

14.Instrumentele de tip CASE pot sa asigure urmatoarele facilitati:

e. Suport pentru metode de analiza si proiectare
f. Stocarea si regasirea datelor din depozitul central
g. Generarea documentatiei de realizare
h. Generarea automata a codului pornind dela modelele conturate

ALTE INTREBARI

35. In abordarea orientata obiect modelarea aspectelor statistice ale unui sistem se realizeaza
prin:
e. Diagrama de activitate
f. Diagrama de secventa
g. Diagrama de clase
h. Diagrama de componente

36. Care din urmatoarele variante consttuie caracteristici ale sistemelor informatice:
e. Este inclus in cadrul sistemuluiinformational-decizional
f. Se ocupa de culegerea, stocarea si prelucrarea automata a datelor
g. Include sistemul informational-decizional
h. Are rolul de a asista sau participa la procesul decizional

37. La proiectarea situatiilor cu rezultate finale machete:

e. Este reprezentarea de detaliu a unei situatii de iesire
f. Cuprinde antetul. Titlul, elementele fixe, capul de tabel si date elementare
g. Contine specificatii care servesc utilizatorului
h. Contine specificatii care servesc programului
38. O metodologie de realizare a unui sistem informatic trebuie sa curpinda:
e. Etepele si procesele de realizare
f. Detalii privind tehnologiile de implementare si limbajele de programare utilizate in
constructia SGBD
g. Tehnicile, procedurile,instrumentele, normele si standardele de utilitate
h. Regulile de formalizare a componentelor sistemului informatic

39. DIagramele de stare din UML:

e. Modeleaza aspectele functionale ale unui sistem
f. Descriu cronologic interactiunea dintre obiecte
g. Modeleaza starea dinamica a unui obiect specific
h. Contin linii de viata si stari compuse

40. Reprezinta caracteristici functionale ale sistemelor informatice executive:

e. Facilitatile de gestiune a resurselor umane
f. Facilitatile de agregare a datelor
g. Facilitaile de analiza a tendintelor
h. Facilitatile de gestiune a echipamentelor

41. In limbajul BPMN un eveniment are urmatoarele caracterisitici:

e. Reprezinta un obiect de conexiune
f. Afecteaza fluxul unui model
g. Este atomic sau non-atomic
h. Controloeaza convergenta unor fluxuri de control

42. Studiul iesirilor sistemului informational sub aspectul numarului de exemplare, destinatiei
fiecarui exemplar, corelatiilor logice dintre indicatori, algoritmilor ce stau la baza elaborarii
acestora, periodicitatea, frecventa, continutul informational,forma de prezentare, poate
folosi la:
c. estimarea necesarului de hartie de imprimanta
d. elaborarea programelor

43. Capacitatea unui sistem de coduri reprezinta:

b. totalitatea combinatiilor distincte posibil e realizat din simbolurile ce compun codul

44. Care din urmatoarele activitati sunt parcurse la realizarea unui sistem de coduri:
1.Identificarea multimii elementelor ce urmeaza a fi codificate
5.Alegerea tipului de cod
 7.Determinarea ciferi de control
9.Atribuirea codurilor elementelor multimii de codificat
10. Intretinerea nomen-clatorului de coduri

45. Ciclul de viata al sistemului informatic:

b. Incepe cu decizia de realizare a sistemului informatic si se inchide cu decizia de
abandonare a acestuia in forma existenta si inlocuirea lui cu un nou sistem

46. Sistemul informatic are ca obiectiv principal:

c. Cresterea exactitatii preciziei informatiilor
d. Cresterea gradului de incarcare a capacitatilor existente si reducerea duratei ciclului de
fabricatie

47. Cifra de control din cod ete folosita pentru:

b. Verificarea corectitudintii codului in procesul de culegere, transmitere si prelucrare a
datelor

48. In etapa de proiectare detaliata a sistemelor informatice se realizeaza documentatia pentru:

b. Proiectul logic si tehnic de detaliu

49. Conditiile de implementare a sistmelor informatice sunt:

e. Difuzarea instructiunilor de executare a procedurilor
f. Asigurarea fondului informational
g. Asigurarea conditiilor organizatorice
h. Instruirea personalului utilizator

50. Studiul si analiza sistemului existent are ca obiectiv principal:

b. Studiul fluxurilor tehnologice

51. Definitivarea documentatiei sistemului proiectat se realizeaza in etapa:

b. Implementarea sistemului informatic

52. Care din urmatoarele cerinte trebuie respectate la proiectarea unui sistem de coduri:
d. Unicitatea
e. Elasticitatea
f. Operationalitatea

53. Studiul intrarilor sub aspectul sursei, destinatiei, periodicitatii, frecventei, numarului de
caractere ce urmeaza a fi prelucrate si stocate, forma de prezentare, conditii de validare,
folosesc la:
b. Estimarea necesarului de echipamente de culegere si transmitere a datelor
54. Schema functionala a fiecarui subsitem aplicatie informatica se elaboreaza in etapa:
b. Proiectarea de detaliu

55. Care din urmatoarele criterii nu stau la baza evaluarii sistmului existent:
b. Evaluarea resurselor materiale, umane si financiare necesare realizarii sistemului
informatic

56. Alegerea tipurilor de modele matematice ce urmeaza a fi utilizate a sistemului informatic se

face in etapa:
b. Proiectarea de ansamblu

57. Sistemul infomatic este un ansamblu de:

c. Elemente intercorelate functional pt automatizarea procesului
d. Obtinere a informatiilor necesare fundamentarii deciziilor

58. Care din urmatoarele cerinte nu constituie un principiu de realizare a sistemelor:

c. Participarea nemijlocita a conducerii unitatii la conceperea sistemului informatic
d. Asigurarea unui nivel tehnic ridicat al solutiilor adoptate

59. Care din urm obiective ale sistmului informatic nu afecteaza in mod direct functionarea
sistemului informational:
b. Cresterea prestigiului firmei

60. Prin “iesirile” unui sitem informatic se intelege totalitatea:

b. Informatiilor furnizate de sistem beneficiarilor interni si externi

61. Sistemul informatic urmareste in principal:

b. Asigurarea conducerii cu informatiile reale si in timp util, necesare fundamentarii si
elaborarii operative a deciziilor
62. Documentatia elaborata la sf fiecarei etape de realizare a sistemului informatie are,in
principal, rolul de:
c. Asigurare a comunicarii intre echipele de speciALISTI IMPLICATI IN REALIZARA SITEMULUI
INFORMATIC
d. PREZENTAREA A DEFICINTELOR SISTEMULUI ACTUAL
63. Caredin urm activitati nu contribuie la realizarea(proiectarea) unui sistem de coduri
b. Verificarea cifrei de control in procesul de prelucrare si transmitere a datelor

64. Conform metodologiei SSADM, modelul logic al sistemului proiectat se obtine pe baza:
B. cerintelor functionale si a modelului logic al sistemului existent

65. In cazul metodologiei SSADM, in etapa de proiectare a noului sistem, intrarile si iesirile pt
noul sistem se vor identifica din:
b. Diagrama de flux a datlor, nivelul funza, a modelului fizic al sistemului existent

66. Tehnica concordantei intrari- iesiri privind analiza si proiectarea sistemelor informatice nu
ofera posibilitatea pentru:
b. Definirea obiectivelor sistemului informatic

67. Ce criterii seau in vederein etapizarea activitatilor de realizare a sistemelor informatice:

b. Diferitele categorii de personal antrenate in activitatea de realizare a sistemelor
informatice precum si omogentitatea activitatilor de realizat

68. Proiectarea fizica de detaliu a intrarilor sistemului informaticc presupune:

iiiiiiiiiiiiiiiiiiiiiiiiiiiiii. Proiectrea machetelor documentelor primare de pe care operatorul
culege datele
 ACADEMIA DE STUDII ECONOMICE BUCUREŞTI
FACULTATEA DE CIBERNETICĂ, STATISTICĂ ŞI INFORMATICĂ ECONOMICĂ

P RO I E C TA R E A S I S T E M E LO R
I N F O R M AT I C E

-INTRODUCERE-

BUCUREȘTI
2020-2021
 Însuşirea competențelor necesare utilizării
OBIECTIVUL conceptelor, teoriilor, principiilor, metodelor,
GENERAL AL proceselor și instrumentelor tehnologice în
DISCIPLINEI scopul realizării unor sisteme informatice prin
parcurgerea tuturor etapelor specifice ciclului
de dezvoltare.

2
OBIECTIVE SPECIFICE ALE
DISCIPLINEI
• Însușirea etapelor de realizare a unui sistem informatic.
• Identificarea, interpretarea și modelarea cerințelor pentru proiectare
și dezvoltarea de noi sisteme informatice.
• Folosirea noțiunilor economice în soluționarea de probleme prin
dezvoltarea de subsisteme informatice noi sau sisteme informatice
în organizație.
• Utilizarea metodelor de analiză și proiectare specifice dezvoltării de
sisteme informatice.
• Definirea cerințelor și caracteristicilor de actualizare a sistemelor
informatice din organizație.
• Elaborarea de studii de specificații pentru proiectarea și realizarea
de componente ale sistemelor informatice.
3
NECESITATE

Disciplină integratoare

Oferă o viziune de ansamblu asupra procesului de

dezvoltare software

Ajută la clarificarea și înțelegerea etapelor necesare pentru

realizarea unui sistem informatic

Folosește standarde în domeniu

Acoperă o varietate de activități specifice dezvoltării de

software

Asigură competențe necesare pentru absolvenții cu

specializarea în informatică

4
ACTIVITĂȚI ÎN DEZVOLTAREA
DE SOFTWARE

Analizează nevoile
Creează o varietate de Recomandă actualizări
utilizatorilor și apoi
modele și diagrame care pentru programele și
proiectează, testează și
arată ce trebuie să facă sistemele existente ale
dezvoltă software pentru sistemul clienților
a satisface aceste nevoi

Proiectează fiecare
Documentează fiecare
componentă a unei Asigură că un sistem
aspect al unei aplicații sau
aplicații sau a unui sistem continuă să funcționeze
al unui sistem ca referință
și planifică modul în care normal prin întreținerea și
pentru întreținerea și
componentele vor testarea software-ului
funcționa împreună actualizările viitoare

Colaborează cu alți
specialiști în informatică
pentru a crea software de
calitate

5
 STRUCTURA CURSULUI

Modul 1 Modul 2 Modul 3 Modul 4 Modul 5

• Sisteme • Analiza • Managementul • Proiectarea • Implementarea

informatice – sistemelor proceselor de sistemelor sistemelor
aspecte informatice. afaceri informatice. informatice:
generale, Analiza • Limbajul Proiectarea strategii de
ciclul de viață ➢ Funcțională BPMN: notații ➢ Funcționalității testare și
& dezvoltare ➢ Statică și exemple ➢ Mecanismelor implementare
• Metodologii ➢ Dinamică de stocare • Mentenanța
de realizarea • Diagrame ➢ Interfețelor sistemelor
a SI UML pentru informatice
➢ Arhitecturii
• Identificarea analiza
cerințelor SI sistemului
• Limbaje
pentru
specificarea
cerințelor SI

6
MODALITATE EVALUARE
• Examen final – 50%
– Subiecte tip grilă
• Seminar – 50%
• Condiţii de intrare în examen:
– susținerea proiectului, la seminar
– minim nota 5 la seminar
• Condiție de promovare a examenului: minim nota 5
• REEXAMINARE: se susţine examen + se reface proba de seminar
nesusţinute
• Punctaj BONUS – maxim 1,5p la nota de examen
– 3 teste grile – la curs
– 1 test = 0, 5p bonus
– Punctajul bonus se obține pentru scor minim 70% per test.
7
RESURSE
• https://online.ase.ro/
• Ion Lungu, Gheorghe Sabău, Manole Velicanu, Mihaela Muntean,
Simona Ionescu, Elena Posdarie, Daniela Sandu - Sisteme informatice.
Analiză, proiectare, implementare, Ed. Economica, Bucuresti, 2003
• Anca Andreescu - Dezvoltarea sistemelor software pentru managementul
afacerilor, Ed. ASE, 2010
• A. Dennis, B. H. Wixom and D. Tegarden - Systems analysis and design:
An object-oriented approach with UML, John wiley & sons,
2015. Disponibil la:
http://www.arxen.com/descargas/PulzarCloud/Books/systems-analysis-and-design-with-
uml-5th-edition.pdf
• Specificaţiile OMG pentru UML. Disponibil la
https://www.omg.org/spec/UML/2.5.1/PDF/
• Specificaţiile OMG pentru BPMN. Disponibil la
https://www.omg.org/spec/BPMN/2.0/PDF

8
CADRE DIDACTICE TITULARE

• Conf. univ. dr. Alexandra CORBEA (FLOREA)

➢ alexandra.corbea@ie.ase.ro

• Conf. univ. dr. Anca ANDREESCU

➢ anca.andreescu@ie.ase.ro
• Prof. univ. dr. Ramona BOLOGA
➢ ramona.bologa@ie.ase.ro
• Prof. univ. dr. Ion LUNGU
➢ ion.lungu@ie.ase.ro

9
CUPRINS

Sistemul și componentele sale

Piramida datelor

Sisteme informatice

Ciclul de viață și de dezvoltare

Strategii de informatizare

10
CONCEPTUL DE SISTEM

• Sistemul este un fenomen omniprezent.

• Putem spune că întâlnim sisteme peste tot.
• Dacă ceva este organizat sistematic, atunci se așteaptă să dea
rezultate calitative.
• Cu toții am văzut și am experimentat sisteme din viața reală:
sistemul educațional, sistemul politic, sistemul pentru
prognoză meteo, sisteme pentru rezervări de bilete, sisteme
de admitere în învățământ.

11
CONCEPTUL DE SISTEM

• Un sistem este un ansamblu de componente

intercorelate funcțional care lucrează împreună pentru a
realiza anumite obiective.
• Pentru sistemele informatice, aceste obiective țin de
automatizarea obținerii informaților necesare
managementului în procesul de fundamentare și
elaborare a deciziilor.

12
SISTEMUL ȘI COMPONENTELE SALE

Granița
Decidenți

Produs/
Intrări Procese Ieșiri Serviciu

• Materii prime
• Cerere
• Constrângeri
• Feedback Mediu

13
SISTEMUL ȘI COMPONENTELE SALE
• Componentele tipice ale unui sistem sunt:
✓intrările
✓ procesele (sau procesarea)
✓ieșirile
✓decidenții
• Granița este conceptul care separă sistemul de mediul său. Uneori, pentru
un sistem, granița acționează ca o interfață cu mediul în care acesta
operează.
• Un sistem care interacționează cu mediul său se numește sistem deschis.
• În contrast, un sistem care nu interacționează cu mediul său se numește
sistem închis. Sistemele închise funcționează ca un fel de cutie neagră
sau recipient izolat. Din moment ce nu acceptă intrări din mediul său și
nu returnează nimic mediului, un sistem închis nu poate fi reprezentativ
pentru o organizație reală.
• Majoritatea sistemelor din viața reală sunt sisteme deschise. 14
SISTEMUL ȘI COMPONENTELE SALE
• Intrările includ acele elemente și informații care sunt furnizate sistemului.
Intrările tipice pentru un sistem pot fi materii prime, informații legate de
cerere de produse/servicii, reguli impuse de guvern sau autorități, feedback-
ul clienților și constrângerile de mediu sau specifice domeniului.
• Procesarea reprezintă un set de procese responsabile, în principal, de
prelucrarea și transformarea intrărilor în ieșiri. Această componentă
cuprinde principalele proceduri necesare pentru a obține produsele sau
serviciile dorite.
• Ieșirile reprezintă cantitatea de informații, produsele sau serviciile
(finalizate sau semi-finalizate), tangibile sau intangibile obținute de sistem
după procesarea intrărilor. Ieșirile sunt destinate utilizatorilor sistemelor.
• Feedback-ul reprezintă informațiile furnizate înapoi în cadrul sistemului.
De obicei, feedback-ul provine din mediu în cazul unui sistem deschis.
Există două tipuri de feedback: feedback pozitiv și negativ, ambele putând
să ducă la îmbunătățirea sistemului.
15
PIRAMIDA DATELOR

Complexitate
Inteligență

S Înțelepciune (experiență)

Cunoștințe (sinteză)

Informații (analiză)

Date (procesare)
Volum

Piramida DIKW – Data Information Knowledge Wisdom

TPS - Transaction Processing Systems, DSS - Decision Support Systems,

MIS- Management Information Systems, KBS – Knowledge Based Systems,
16
WBS – Wisdom Based Systems, IS – Intelligent Systems
PIRAMIDA DATELOR
• Piramida datelor este un model care cuprinde diferite niveluri ierarhice de
date, informații, cunoștințe, înțelepciune și inteligență, împreună cu
tipurile de sisteme asociate acestora.
• Datele sunt entități elementare care formează baza piramidei. Datele sunt
definite sub formă de observații brute.
• Odată ce datele sunt colectate și procesate, vor fi generate informațiile.
Prelucrarea datelor este operația cheie care transformă datele în
informații. Informațiile au asociate un factor de utilizare și de
semnificație.
• Cunoștințele reprezintă colectarea adecvată de informații cu intenția de a
deveni utile.
• Cunoștințele dobândite sunt evaluate în termeni de timp, experiență și
etică pentru a genera înțelepciune.
• Inteligența se bazează pe abilitatea de a folosi cunoștințele și
înțelepciunea dobândite.
17
PIRAMIDA DATELOR
Date: 7
Informații: 7 grade C
Cunoștințe: 7 grade C, astăzi la ora 10.00 în București
Înțelepciune: Este nevoie să îmi pun o haină groasă când ies
din casă
Inteligență: Regulile implementate de o aplicație mobilă care
mă sfătuiește ce anume să port în funcție de condițiile
meteorologice prognozate (temperatură, umiditate, precipitații,
vânt)

18
COMPONENTELE SISTEMULUI INFORMATIC

HARDWARE

SOFTWARE

COMUNICAŢIILE

SISTEM INFORMATIC BAZA ŞTIINŢIFICĂ

ŞI METODOLOGICĂ

BAZA
INFORMAŢIONALĂ

UTILIZATORII

CADRUL
ORGANIZATORIC

19
COMPONENTELE SISTEMULUI INFORMATIC
• HARDWARE-ul sistemului informatic este constituit din totalitatea mijloacelor
tehnice de culegere, transmitere, stocare şi prelucrare automată a datelor.
• SOFTWARE-ul sistemului cuprinde totalitatea programelor pentru funcţionarea
sistemului informatic, în concordanţă cu funcţiile şi obiectivele ce i-au fost
stabilite.
• COMUNICAŢIILE se referă la totalitatea echipamentelor şi tehnologiilor de
comunicaţie a datelor între sisteme.
• BAZA ŞTIINŢIFICO-METODOLOGICĂ este constituită din modele ale
proceselor şi fenomenelor economice, metodologii, metode şi tehnici de realizare
a sistemelor informatice.
• BAZA INFORMAŢIONALĂ cuprinde datele supuse prelucrării, fluxurile de
date și nomenclatoarele de coduri.
• UTILIZATORII reprezintă personalul necesar funcţionării sistemului informatic:
utilizatori finali, analiști, proiectanți, programatori, testeri etc.
• CADRUL ORGANIZATORIC include regulamentul de organizare şi
funcţionare a organizaţiei în care funcţionează sistemul informatic. 20
OBIECTIVE ALE SISTEMELOR INFORMATICE

• Obiective ce afectează activităţile de bază din cadrul organizaţiilor

economice, cum ar fi:
✓creşterea gradului de încărcare a capacităţilor de producţie
existente şi reducerea duratei ciclului de fabricaţie;
✓creşterea volumului producţiei;
✓optimizarea stocurilor;
✓creșterea profitului.

• Obiective ce afectează funcţionarea sistemului, cum ar fi:

✓creşterea vitezei de răspuns a sistemului la solicitările
beneficiarilor;
✓creşterea exactităţii şi preciziei în procesul de prelucrare a
datelor şi informare a conducerii.
21
AVANTAJE OFERITE DE SISTEMELE
INFORMATICE

• Oferă posibilitatea simulării facile a proceselor şi fenomenelor

economice la nivel micro şi macroeconomic.
• Asigură o corelare mai judicioasă a obiectivelor cu resursele.
• Prin implementarea unor modele matematice în cadrul
sistemelor informatice apare posibilitatea alegerii ofertei
(variantei) optime în diferite domenii de activitate.
• Sistemele informatice imprimă valenţe sporite de ordin
cantitativ şi calitativ informaţiilor furnizate decidenţilor sub
aspectul exactităţii, realităţii, oportunităţii, viteze de răspuns,
formei de prezentare, completitudinii informaţiei şi costului
informaţiei.
22
CONSTRUCȚIE/
D E Z V O LTA R E

23
 CICLUL DE VIAŢĂ ŞI DE DEZVOLTARE
• Ciclul de viaţă al unui sistem informatic este un şablon pentru ordonarea
activităţilor de realizare a sistemului informatic, cuprinzând intervalul de
timp care începe cu decizia de elaborare a unui sistem informatic şi se
încheie cu decizia de abandonare a acestuia şi înlocuirea lui cu un nou
sistem informatic.
• Ciclul de dezvoltare al sistemului informatic este cuprins în ciclul de viaţă
al sistemului informatic. El include intervalul de timp de la luarea deciziei de
realizare a unui sistem informatic până în momentul intrării sistemului în
exploatare.
Ciclul de viaţă

Ciclul de dezvoltare

Decizia de a dezvolta un Utilizat de către Abandonarea sau înlocuirea

sistem informatic beneficiar sistemului informatic
24
CICLUL DE VIAŢĂ ŞI DE DEZVOLTARE

Planificare

Mentenanță Analiză

Punere în
funcțiune Proiectare

Testare Implementare
25
CICLUL DE VIAŢĂ ŞI DE DEZVOLTARE
Activităţile componente ale ciclul de viaţă al sistemelor informatice sunt grupate în mai
multe moduri, în etape sau faze.
1. Planificarea
▪ Este fundamentală pentru a înțelege de ce un sistem informatic ar trebui să fie
construit și pentru a stabili modul în care echipa de dezvoltare va planifica
construirea acestuia.
▪ Include ca faze distincte:
A. Stabilirea oportunității:
– Identifică aspecte care necesită automatizare și explică modul în care un sistem va susține aceste
nevoi și va genera valoare pentru companie.
– Se identifică și se formulează cerințele globale privind realizarea sistemului informatic.
– Se pot realiza analize de tipul cost/beneficiu sau studii de fezabilitate (Cum va reduce costurile
sau va crește veniturile noul sistem?).
– În final, se decide dacă dezvoltarea sistemului este oportună pentru companie.
B. Inițierea managementului proiectului:
– După aprobare, are loc demararea activităților specifice pentru managementul proiectului.
– Rezultatul este un plan de proiect, care descrie modul în care echipa se va ocupa de realizarea
sistemului. 26
CICLUL DE VIAŢĂ ŞI DE DEZVOLTARE
2. Analiza sistemului este etapa în care:
▪ are loc investigarea sistemului/sistemelor actuale și identificarea oportunităților de
îmbunătățire;
▪ se realizează identificarea cerințelor folosind tehnici precum interviurile sau
chestionarele;
▪ se analizează cerințele funcționale şi de calitate ale sistemului;
▪ se identifică, printre altele: ce funcţii trebuie să îndeplinească sistemul, ce date
trebuie prelucrate, ce rezultate trebuie să se obţină, ce tip de interfață va fi utilizată;
▪ se răspunde, în esență, la întrebările „Cine va folosi sistemul?”, „Ce trebuie să facă
sistemul?”, „Unde și când va fi folosit?” ;
▪ nu trebuie să se țină cont de tehnologia care va fi aleasă pentru implementare;
▪ folosind diferite modalități de reprezentare textuală și grafică are loc dezvoltarea
unui concept pentru noul sistem;
▪ calitatea rezultatelor acestei etape este deosebit de importantă, deoarece acestea
reprezintă o punte de legătură între cerințele clienților și modelele arhitecturale și
de implementare care se vor realiza în etapele ulterioare. 27
CICLUL DE VIAŢĂ ŞI DE DEZVOLTARE
3. Proiectarea sistemului este etapa care:
▪ răspunde, în esenţă, la întrebarea “Cum vor fi realizate cerinţele identificate în
analiză?”;
▪ decide cum va funcționa sistemul, în ceea ce privește componentele hardware,
software și infrastructură de rețea;
▪ ia în considerare particularităţile tehnologiilor alese pentru implementare;
▪ în cele mai multe cazuri, sistemul va extinde sau va modifica infrastructura care
există deja în companie;
▪ are în vedere o multitudine de aspecte tehnice, cum ar fi:
• modularizarea şi stabilirea arhitecturii sistemului;
• modul de organizare şi structurare a datelor;
• proiectarea algoritmilor necesari pentru prelucrări;
• proiectarea în detaliu a interfeţei cu utilizatorul.
▪ livrabilele reprezentând modelul de proiectare al sistemului sunt predate echipei de
programare pentru implementare.
28
CICLUL DE VIAŢĂ ŞI DE DEZVOLTARE
4. Implementarea sistemului:
▪ implică realizarea efectivă a aplicațiilor conform specificațiilor din etapa de
proiectare;
▪ include activități specifice precum scrierea de cod, reutilizarea de cod, folosirea
de instrumente de tipul IDE etc.
5.Testarea sistemului:
▪ pornește de la premisa că va implementa și se va testa separat fiecare modul al
sistemului, iar integrarea și testarea de ansamblu presupune ca modulele
implementate și testate în etapa anterioară să se integreze;
▪ ulterior, se testează sistemul în ansamblu pentru a verifica corectitudinea
implementării relațiilor dintre module și funcționalitatea sistemului în ansamblu.
6. Punerea în funcţiune a sistemului:
▪ presupune instalarea sistemului și instruirea utilizatorilor;
▪ experimentarea în condiții reale este deosebit de importantă deoarece sistemul
este validat folosind seturi de date reale și în condiții reale de funcționare.
7. Exploatarea şi mentenanţa sistemului:
▪ pot duce la identificarea de cerințe incomplete sau incorecte, erori în sistem,
posibilități de extindere etc.
29
STRATEGII DE INFORMATIZARE

• Strategiile, abordările şi tehnicile de dezvoltare a sistemelor

informatice s-au reînnoit şi perfecţionat în mod continuu.
• La început, dezvoltarea sistemelor informatice se concentra doar pe
utilizarea bazelor de date şi a limbajelor de programare.
• Treptat, componentele şi pachetele software comercializate, precum
şi sistemele integrate de tip ERP realizate de producătorii de software
şi-au facut simţită prezenţa din ce în ce mai mult pe piaţă, oferind
organizaţiilor o alternativă la dezvoltarea integrală, de la zero, a
sistemelor informatice.
• Recent, prin oferirea de software sub formă de servicii prin
intermediul Internet-ului (SaaS – Software as a Service), organizaţiile
pot folosi software fără a avea instalate propriile aplicaţii.

30
STRATEGII DE INFORMATIZARE

• Strategiile, abordările şi tehnicile de dezvoltare a sistemelor

informatice s-au reînnoit şi perfecţionat în mod continuu.
• La început, dezvoltarea sistemelor informatice se concentra doar pe
utilizarea bazelor de date şi a limbajelor de programare.
• Treptat, componentele şi pachetele software comercializate, precum
şi sistemele integrate de tip ERP realizate de producătorii de software
şi-au facut simţită prezenţa din ce în ce mai mult pe piaţă, oferind
organizaţiilor o alternativă la dezvoltarea integrală, de la zero, a
sistemelor informatice.
• Recent, prin oferirea de software sub formă de servicii prin
intermediul Internet-ului (SaaS – Software as a Service), organizaţiile
pot folosi software fără a avea instalate propriile aplicaţii.

31
STRATEGII DE INFORMATIZARE

• Există două strategii principale în informatizarea activităţilor

organizaţiilor :
1. Achiziţia sistemului
2. Construcţia sistemului
❑ în interiorul organizaţiei
❑ externalizarea – de către un furnizor extern de servicii software
1. Achiziţia Sistemului
• Este prima strategie de dezvoltare a unui sistem informatic ce trebuie
luată în calcul.
• Presupune utilizarea de către organizaţie a unor produse existente, cu
posibilitatea configurării şi personalizarii .
• Categorii de produse existente: pachete software comerciale, sisteme
integrate de tip ERP, SaaS.
32
STRATEGII DE INFORMATIZARE
Pachete software comerciale
• Sunt disponibile pentru vânzare sau închiriere către publicul general
• Se adresează, în general, organizaţiilor mici şi mijlocii
• Deseori, au o capacitate limitată de personalizare pentru nevoi speciale
Sisteme integrate de tip ERP
• Facilizează integrarea tuturor proceselor de afaceri din unităţile
departamentale ale organizaţiei şi gestionează conexiunile cu organizaţiile
externe
• Operează în timp real
• Au o bază de date comună pentru toate aplicaţiile
• Sunt formate dintr-un set de module care pot funcţiona şi independent
• Implică un efort semnificativ de configurare şi personalizare a soluţiei
• Se adresează tuturor tipurilor de organizaţii

33
STRATEGII DE INFORMATIZARE

Software as a Service (SaaS)

• Constituie o modalitate de a oferi software în care aplicaţiile şi
datele asociate lor sunt stocate centralizat de către furnizorul
de servicii şi sunt, tipic, accesate de către clienţi prin
intermediul Internet-ului, folosind un browser Web
• Pot suporta configurare, mai puţin personalizare
• Pot fi rapid actualizate
• Multe aplicaţii oferă utilizatorilor funcţii de colaborare şi
partajare de informaţii
• Sunt găzduite în cloud, de aceea, timpul de răspuns şi
problemele de securitate constituie factori critici

34
STRATEGII DE INFORMATIZARE

Informatizare prin achiziţia de software

35
STRATEGII DE INFORMATIZARE
2. Construcţia Sistemului
• Poate fi realizată în interiorul organizaţiei sau externalizată
• Se foloseşte, spre exemplu, pentru cerinţe specifice unice ale organizaţiei
• Este metoda adoptată de către dezvoltatorii de software şi de tehnologii
informatice
• Este o soluţie consumatoare de timp şi resurse
• Implică parcurgerea tuturor paşilor specifici ciclului de dezvoltare a unui
sistem informatic

Informatizare prin realizarea de software 36

CURSUL 2...

• Identificarea cerințelor sistemelor informatice

• Limbaje pentru specificarea cerințelor sistemelor informatice

37
 ACADEMIA DE STUDII ECONOMICE BUCUREŞTI
FACULTATEA DE CIBERNETICĂ, STATISTICĂ ŞI INFORMATICĂ ECONOMICĂ

P RO I E C TA R E A S I S T E M E LO R
I N F O R M AT I C E

-CURS 2-

BUCUREȘTI
2020-2021
IDENTIFICAREA CERINŢELOR SISTEMELOR
INFORMATICE

Cuprins
✓Problematica ingineriei cerinţelor
✓Categorii de cerinţe ale sistemelor informatice
✓Cerinţe non-funcţionale
✓Tehnici pentru identificarea cerinţelor
✓Caracteristici de calitate ale cerinţelor
PREMIZE

➢ Slaba calitate a cerinţelor este în mod constant pe primele

locuri în ierarhia cauzelor care duc la eşecul proiectelor software.
➢ O explicaţie ar fi aceea că echipele de dezvoltare alocă prea
puţin timp înţelegerii problemelor reale ale afacerii, a nevoilor
utilizatorilor sau a naturii mediului în care va rula sistemul.
➢ De asemenea, dezvoltatorii încearcă să furnizeze cât mai rapid
soluţii tehnice, plecând însă de la înţelegerea insuficientă a
cerinţelor problemei.
IDENTIFICAREA CERINȚELOR

 Reprezintă procesul prin care culegem și documentăm cerințele

sistemului.
 Identificarea şi definirea detaliată a cerinţelor se realizează de
comun acord cu beneficiarul.
 Pot fi identificate:
✓ Cerinţe care rezolvă sau reduc deficienţele sistemului existent.
✓ Cerinţe care exprimă noi facilităţi . Ele nu sunt asigurate de
vechea implementare a sistemului.
IDENTIFICAREA CERINȚELOR

 Aspecte practice:
▪ Cu cât descoperim mai multe cerințe, cu atât va fi mai bun
sistemul construit.
▪ Cerințele se schimbă.
▪ Pot exista cerințe care sunt deja implementate.
▪ Cerințele pot fi:
✓ explicite – furnizate de beneficiar;
✓ implicite – le descoperă analistul.
PROBLEMATICA INGINERIEI CERINŢELOR

• Pentru a fi siguri că un sistem informatic rezolvă în mod corect

o anumită problemă, trebuie, mai întâi, să se înţeleagă în mod
corect problema care trebuie rezolvată. În acest sens sunt
necesare descoperirea, înţelegerea, specificarea şi analiza
următoarelor componente:
➢CE problemă trebuie rezolvată;
➢DE CE o astfel de problemă necesită rezolvare;
➢CINE este implicat şi va fi responsabil de rezolvarea acestei
probleme.
• În mare, aceste trei componente, stau la baza Ingineriei
Cerinţelor Sistemelor Informatice.
PROBLEMATICA INGINERIEI CERINŢELOR

Activităţi de bază pentru construirea unui model al cerinţelor

PROBLEMATICA INGINERIEI CERINŢELOR

• Deseori, dificultăţile în modelarea şi analiza cerinţelor provin din înţelegerea

insuficientă a părţii de logică a sistemului/aplicatiei, cunoscută şi sub
denumirea de logică a afacerii.
• Logica afacerii reprezintă elementul definitoriu pentru o afacere aflată în
proces de modelare şi de automatizare, ea incluzând atât regulile afacerii,
cât şi fluxul de lucru (procesele) din cadrul afacerii prin care se descrie
modul de transfer al documentelor sau al datelor de la un participant
(persoană fizică sau sistem software) la altul.
• În dezvoltarea de sistemelor informatice, logica afacerii are ca obiective:
– modelarea obiectelor afacerii din lumea reală (precum stocuri, clienţi,
produse);
– gestionarea modului de stocare a obiectelor afacerii (maparea obiectelor
afacerii în tabelele bazei de date);
– descrierea modului în care obiectele afacerii interacţionează între ele.
CATEGORII DE CERINŢE ALE SISTEMELOR INFORMATICE

• În dezvoltarea sistemelor informatice, o cerinţă defineşte un deziderat pe

care acesta trebuie să-l îndeplinească, ca răspuns la necesităţile utilizatorilor
săi.
• Ea reprezintă o parte a scopului pentru care se dezvoltă un proiect
informatic.
• Cerinţele dictează şi modul în care sistemul trebuie să răspundă la
interacţiunea cu utilizatorul.
• În linii mari, dezvoltatorii trebuie să aibă în vedere următoarele aspecte
legate de cerinţele unui sistem:
– folosirea unui limbaj tehnic: cerinţele trebuie întotdeauna specificate în
limbajul utilizatorului, putând include aici şi jargonul domeniului analizat;
– relaţia cu obiectivele afacerii: fiecare cerinţă trebuie în mod clar legată de
obiectivele oamenilor de afaceri.
CATEGORII DE CERINŢE ALE SISTEMELOR INFORMATICE
• Prin procesul de inginerie a cerinţelor se urmăreşte culegerea,
elaborarea, corectarea şi adaptarea unui volum mare de specificaţii,
care diferă în ceea ce priveşte scopul şi modul de exprimare. O astfel
de diferenţiere se poate realiza între cerinţele:
– descriptive;
– prescriptive.
• Specificaţiile descriptive prezintă proprietăţi pe care sistemul trebuie
să le aibă indiferent de modul în care acesta va funcţiona. Astfel de
proprietăţi sunt generate, de obicei, de legi ale naturii sau de
constrângeri fizice. Exemple de specificaţii descriptive:
❑Aceeaşi carte nu poate fi împrumutată de doi abonaţi în acelaşi timp.
❑Dacă o cameră a hotelului este în renovare, atunci aceasta nu poate fi
ocupată.
CATEGORII DE CERINŢE ALE SISTEMELOR INFORMATICE

• Specificaţiile prescriptive descriu proprietăţile pe care se doreşte să le

aibă sistemul informatic şi pe care acesta le îndeplineşte sau nu, acest
lucru depinzând de modul în care sistemul va funcţiona
Exemple de specificaţii prescriptive sunt:
❑Un abonat nu poate să împrumute mai mult de trei cărţi în acelaşi timp.
❑Un produs trebuie livrat în intervalul orar specificat de cumpărător.

• Distincţia dintre specificaţiile descriptive şi cele prescriptive este

foarte importantă în contextul ingineriei cerinţelor, în sensul că putem
negocia, schimba sau găsi alternative pentru specificaţiile
prescriptive, în timp ce pentru cele descriptive aceste lucruri nu sunt
posibile.
CATEGORII DE CERINŢE ALE SISTEMELOR INFORMATICE

• Prin prisma funcţionalităţii, cerinţele unui sistem sunt de două tipuri:

– funcţionale ;
– non-funcţionale.
• Cerinţele funcţionale definesc funcţiile unui sistem informatic
sau ale componentelor acestuia, prin intermediul unui mulţimi
de intrări, ale comportamentului şi a ieşirilor. În această
categorie putem încadra calcule, detalii tehnice, informaţii
privind procesarea şi manipularea datelor, precum şi alte
funcţionalităţi care arată, de exemplu, cum trebuie realizat un
caz de utilizare.
CATEGORII DE CERINŢE ALE SISTEMELOR INFORMATICE

• Cerinţele non-funcţionale surprind criteriile care pot fi folosite

pentru a analiza aspectele legate de operaţionalitatea sistemului,
şi nu de comportamentul acestuia.

• Acestea impun constrângeri la nivel de proiectare sau de

implementare asupra cerinţelor funcţionale (de exemplu, cerinţe
legate de performanţă, securitate sau fiabilitate). Cerinţele non-
funcţionale sunt deseori referite prin termenul de calităţi ale
unui sistem, dar pot fi menţionate şi ca atribute de calitate,
obiective de calitate, caracteristici de calitate sau constrângeri.
CERINŢE NON-FUNCŢIONALE

Tipuri de cerinţe non-funcţionale

CERINŢE NON-FUNCŢIONALE
A. Cerinţele de calitate definesc aspecte referitoare la “cât de bine”
trebuie să funcţioneze sistemul. Acestea includ specificaţii legate de:
– Cerinţele de siguranţă care sunt cerinţe de calitate prin care se
preîntâmpină producerea unor accidente sau degradarea mediului.
– Cerinţele de securitate descriu măsuri de protecţie a sistemului
împotriva unor comportamente nedorite.
• Cerinţele de confidenţialitate arată că anumite informaţii nu pot fi
divulgate părţilor neautorizate.
• Cerinţele de integritate arată că anumite informaţii pot fi modificate dacă
acest lucru a fost realizat într-o manieră corectă şi autorizată.
• Cerinţele de disponibilitate se referă la faptul că anumite cerinţe sau
resurse pot fi folosite de către persoanele autorizate atunci când este
necesar.
CERINŢE NON-FUNCŢIONALE
A. Cerinţele de calitate -continuare
– Cerinţele de fiabilitate constrâng sistemul informatic să funcţioneze
aşa cum este de aşteptat şi de dorit, pentru perioade lungi de timp.
Exceptând circumstanţele excepţionale, sistemul trebuie să furnizeze
servicii într-o manieră corectă şi robustă.
– Cerinţele de performanţă impun condiţii asupra modului în care
operează sistemul, cum ar fi, spre exemplu, timpul maxim necesar
pentru execuţia unei operaţii.
– Cerinţele de interfaţă arată cum interacţionează sistemul cu mediul,
utilizatorii, precum şi cu alte sisteme.
CERINŢE NON-FUNCŢIONALE
B. Cerinţele de conformitate impun condiţiile necesare astfel încât sistemul
să funcţioneze în conformitate cu legile naţionale, reglementările
internaţionale, normele sociale, constrângerile politice şi culturale, standarde
etc.
C. Cerinţele arhitecturale impun constrângeri structurale asupra sistemului
informatic, astfel încât acesta să poată funcţiona corespunzător în mediul
unde va fi implementat. Oferă dezvoltatorilor indicaţii privind tipul de
arhitectură potrivită pentru sistem.
D. Cerinţele de dezvoltare sunt cerinţe non-funcţionale care constrâng modul
în care sistemul ar trebui dezvoltat, şi nu felul în care acesta ar trebui să
satisfacă cerinţele funcţionale. Sunt inlcuse aici cerinţe privind costurile de
dezvoltare, planul de livrare şi instalare, detalii referitoare la mentenanţă,
portabilitate etc.
EXEMPLE DE CERINŢE NON-FUNCŢIONALE
• Cerinţe de calitate
– Siguranță
• Sistemul nu trebuie să mai funcționeze dacă temperatura exterioară scade sub 4 grade C.
• Sistemul nu trebuie să mai funcționeze în caz de incendiu.
• Sistemul nu trebuie să mai funcționeze în cazul în care se observă atacuri evidente.
– Securitate
• Permisiunile de acces la date pot fi modificate numai de către administratorul de date al
sistemului.
• Toate datele de sistem trebuie să fie copiate la fiecare 24 ore și copiile de rezervă stocate
într-un loc sigur, care nu se află în aceeași clădire ca și sistemul.
• Toate comunicările externe între serverul de date și clienți trebuie să fie criptate.
– Fiabilitate
• Sistemul trebuie să aibă o disponibilitate de 999/1000 sau 99%. Aceasta este o cerință de
fiabilitate care presupune ca din fiecare 1000 de cereri ale serviciului, 999 trebuie să fie
îndeplinite.
– Performanță
• Sistemul va procesa un minim de 100 tranzacții pe secundă.
EXEMPLE DE CERINŢE NON-FUNCŢIONALE

• Cerinţe de conformitate
– Cerințe legale și de reglementare:
• Toate modificările aduse datelor utilizatorilor trebuie păstrate minim 6 ani.
– Cerințe de licențiere:
• Sistemul este licenţiat pentru a fi utilizat simultan de către maxim 100 de utilizatori.
• Licenţele pentru soluţia de baze de date trebuie să permită lucrul cu până la 4 procesoare
fără limită pentru lucrul cu memoria RAM şi dimensiunea bazei de date.
• Cerinţe arhitecturale
– Persistența datelor va fi asigurată printr-o baze de date relațională.
– Această baze de date va fi Oracle 18c.
– Sistemul va rula 24 de ore pe zi, 7 zile pe săptămână.
• Cerinţe de dezvoltare
– Modulul de raportare inclus în soluţia de bază de date trebuie să conţină un instrument de
dezvoltare de rapoarte adiţionale.
– Modulul de raportare inclus în soluţia de bază de date trebuie să aibă o interfaţa web de
configurare şi acces proprie.
SURSE PENTRU IDENTIFICAREA CERINȚELOR

• Cerințele le identificăm prin două modalități de bază:

1. De la beneficiar prin:
➢Interviuri
➢Ședințe comune
➢Observații directe
➢Prototipizare
2. Prin consultarea artefactelor
➢Documente de intrare
➢Rapoarte de ieșire
➢Legislație
➢....
ARTEFACTE

• Artefactele conțin orice informații existente despre sistem care pot fi culese
din diverse surse:
▪ Documente preexistente despre funcționarea sistemului
▪ Eșantioane de date
▪ Chestionare
▪ Scenarii
▪ Prototipuri de interfețe
▪ Scheme conceptuale
▪ ......
• În primul rând trebuie înțeleasă organizația, chiar și la nivel de bază:
▪ Cu ce se ocupă
▪ Care sunt fluxurile de lucru
▪ Ce politici a adoptat
▪ Cine sunt beneficiarii sistemului
TIPURI DE ARTEFACTE
• Organizația
✓ Organigrame
✓ Planuri de afaceri
✓ Politici
✓ Rapoarte financiare
✓ Procese verbale ale întâlnirilor
✓ Fișe de post

• Domeniu
✓ Cărți, studii, articole
✓ Reglementările din domeniu
✓ Rapoarte privind sisteme similare

• Sistemul existent
✓ Rapoarte privind fluxul de informații, proceduri de lucru, reguli de afaceri
✓ Rapoarte care conțin defecte, reclamații, solicitarea unor schimbări
✓ Manuale de utilizare
ANALIST

• Responsabilități legate de cerințe:

➢ Culege
➢ Documentează
➢ Analizează
➢ Validează
• În cadrul echipei:
➢ Reprezintă legătura dintre client și dezvoltator
➢ Rol important în evoluția proiectului
➢ Gestionează activități în contextul schimbării cerințelor, luării unor noi
decizii de dezvoltare sau apariției unor riscuri
ANALIST

• Documentează specificațiile cerințelor

➢ Modelează cerințele
➢ Reprezentări grafice
➢ Ecuații
➢ Diagrame
➢ Tabele
➢ Prototipuri de interfețe
• Gestionează procesul de validare a cerințelor
➢ Cerințele culese îndeplinesc caracteristicile de calitate necesare pentru
ca sistemul descris să satisfacă nevoile beneficiarului
PROBLEME LEGATE DE IDENTIFICARE CERINȚELOR

✓ Surse distribuite și conflictuale

✓ Dificultatea de a accesa sursele
✓ Cunoștințe tacite/ascunse (Cunoștințe care sunt implicite din punct de vedre
al beneficiarului sau cu care sunt atât de familiarizați încât le consideră de
bun simț și nu simt nevoia să dea explicații suplimentare)
✓ Condiții instabile
✓ Factori sociopolitici
✓ Competiții între departamente
✓ Competiții între indivizi/angajați
✓ Interese divergente
✓ Priorități diferite
✓ Documente neactualizate
✓ Rezistența la schimbare
ABORDĂRI TRADIȚIONALE VS. AGILE
• Abordările tradiționale
✓Încercăm să documentăm cât mai multe cerințe de la început
✓Planifică și documentează
✓Uneori sute sau mii de pagini
✓Definește totul
✓Înregistrează toate presupunerile
✓Explică raționamente, alternative
✓De lungă durată
• Abordările agile
Agile Tradiționale
Indivizi și interacțiuni Procese și instrumente
Software care funcționează Documentație exhaustivă
Colaborare cu clientul Negocierea contractului
Reacție la schimbare Urmărirea unui plan
TEHNICI PENTRU IDENTIFICAREA CERINŢELOR

1. Interviurile
• Intervievarea beneficiarului este cea mai uzuală metodă de
identificare a cerinţelor. Succesul său depinde de implicarea tuturor
părţilor interesate, incluzând aici manageri, acţionari angajaţi, etc. pe
care în continuare îi vom plasa sub titulatura generală de utilizatori.
• Un interviu, în mod normal, se va concentra asupra activităţii
desfăşurate de utilizator în cadrul organizaţiei, a modului în care
implementarea sistemului va influenţa munca sa şi a problemelor pe
care acesta le-a identificat în procesele actuale care au loc în
organizaţie. Interviul poate scoate la iveală cerinţe care nu au fost
iniţial identificate ca făcând parte din obiectivele proiectului, dar şi
cerinţe contradictorii.
TEHNICI PENTRU IDENTIFICAREA CERINŢELOR

1. Interviurile - continuare
• Apariţia cerinţelor contradictorii poate fi derutantă, în sensul că nu
pare firesc ca diferite persoane care lucrează în aceiaşi organizaţie să
aibă viziuni contradictorii asupra aceluiaşi aspect analizat.
Analistul îşi poate pune următoarea întrebare
pertinentă: ”Cum poate o afacere să fie competitivă şi
profitabilă dacă nu există un consens, cel puţin în interiorul ei,
privind modul în care aceasta funcţionează?”

Un posibil răspuns: “…nivelul de detaliu necesar pentru

construirea unei aplicaţii informatice este mai mare decât nivelul de
detaliu necesar pentru a conduce cu succes o afacere.”
INTERVIURI – BUNE PRACTICI

✓ Identificați eșantionul intervievat potrivit pentru acoperirea completă a

problemelor – nu este nevoie de mai mulți angajați care au aceleași
responsabilități sau de toți managerii.
✓ Centrați interviul pe munca intervievaților și pe preocupările acestora.
✓ Luați în considerare și persoana, nu numai rolul acesteia.
✓ Oferiți motivare, puneți întrebări cât mai ușor de înțeles.
✓ Fiți deschiși, flexibili în cazul în care apar răspunsuri neașteptate
✓ Puneți frecvent întrebarea “DE CE?” pentru a clarifica aspectele
neînțelese.
✓ Evitați întrebările care exprimă opinii sau sunt interpretabile sau al căror
răspunsuri sunt evidente sau imposibile pentru intervievat.
✓ Adaptați întrebările la nivelul de expertiză al fiecărui intervievat (trebuie
să cunoașteți responsabilitățile acestora) .
TEHNICI PENTRU IDENTIFICAREA CERINŢELOR

2. Sesiunile comune pentru stabilirea cerinţelor

• Sesiunile comune pentru stabilirea cerinţelor (engl. Join Requirement
Planning- JRP) pot fi asimilate cu efectuarea interviurile tuturor
utilizatorilor (sau cel puţin a unei părţi semnificative a acestora) în
acelaşi timp şi în aceeaşi încăpere.
• Toate persoanele care vor influenţa direcţia în care se dezvoltă
sistemul sunt reunite într-un singur loc pentru a furniza detalii despre
ceea ce trebuie să facă sistemul.
• Este necesară existenţa unui mediator care să modereze aceste
sesiuni, dar şi a unei persoane care să documenteze propunerile
utilizatorilor, ajutându-se, de exemplu, de un proiector şi de un
produs software pentru modelarea vizuală.
TEHNICI PENTRU IDENTIFICAREA CERINŢELOR

3. Cazurile de utilizare
• Cazurile de utilizare descriu interacţiunile dintre utilizatori şi sistem
şi reflectă ceea ce trebuie să facă utilizatorii cu sistemul prin
identificarea funcţiilor importante.
• Un caz de utilizare surprinde secvenţa de interacţiuni dintre sistem şi
actorii externi (cum ar fi persoane, dispozitive hardware sau alte
sisteme software), incluzând şi variante sau extensii ale
comportamentului de bază al sistemului.
• Cazurile de utilizare pot constitui una dintre primele forme de
reprezentare a cerinţelor unui sistem informatic, motiv pentru care ele
sunt potrivite pentru stadiile incipiente ale procesului de dezvoltare
software. Analiştii, împreună cu beneficiarii sistemului, vor trebui să
examineze şi să valideze fiecare caz de utilizare propus
TEHNICI PENTRU IDENTIFICAREA CERINŢELOR

4. Observaţiile şi analizele sociale

• Metodele bazate pe observaţii presupun existenţa unui observator
care să urmărească utilizatorii sistemului şi să noteze informaţii
referitoare la activitatea pe care aceştia o desfăşoară.
• Observaţiile pot fi directe, implicând prezenţa observatorului pe
parcursul executării activităţilor sau indirecte, atunci când activitatea
este vizualizată prin intermediul altor mijloace, cum ar fi o
înregistrare video.
• Metoda prezintă avantajul de a facilita culegerea unor date de calitate
şi este utilă pentru analiza activităţilor şi proceselor reale, prin care se
pot evita eventualele omisiuni sau erori furnizate de o descriere a
fluxului de lucru de către beneficiar .
TEHNICI PENTRU IDENTIFICAREA CERINŢELOR

5. Prototipurile
• Prototipul este util pentru utilizatorul final care va înţelege mai bine ce vrea
sau ce se aşteaptă de la produs şi este util dezvoltatorului pentru a testa unele
tehnici, algoritmi folosiţi, interfeţe realizate etc.
• Referitor la prototip există două abordări :
– prototip de încercare care trebuie să fie rapid, chiar dacă nu perfect şi care
poate fi utilizat pentru validarea interfeţei, pentru particularizarea arhitecturii
pentru a cuprinde cerinţele cât mai bine, sau pentru a valida algoritmi
particulari;
– prototip evolutiv care, dimpotrivă, dezvoltă produsul final astfel încât să se
poată aprecia toate caracteristicile de calitate ale produsului software final; în
general acest prototip nu poate fi rapid, dar permite îmbunătăţirea modelului
prin asigurarea unei calităţi ridicate a produsului software.
CARACTERISTICI DE CALITATE ALE CERINŢELOR
Literatura de specialitate face referire la o multitudine de proprietăţi “dorite” ale
specificaţiilor. În ansablul lor, se urmăreşte ca cerinţele să fie:
• Complete: Documentaţia cerinţelor include toate informaţiile necesare referitoare la
cerinţe: cerinţe funcţionale şi non-funcţionale, constrângeri, cerinţe referitoare la
interfeţele externe, cerinţe ale datelor etc.
• Consistente: Între cerinţele de la acelaşi nivel, nu există conflicte interne care să ducă
la contradicţii. De asemenea, nu trebuie să existe contradicţii între cerinţele de la
niveluri diferite. Se va urmări şi consistenţa terminologiei, astfel încât: a) un cuvânt să
aibă acelaşi sens de fiecare dată când este folosit; b) două cuvinte diferite nu se folosesc
pentru a desemna acelaşi lucru.
• Modificabile: Documentaţia care include cerinţele este organizată şi scrisă într-o
manieră care facilitează modificările ulterioare şi, în acest sens, o cerinţă trebuie să fie:
– Neredundantă: Fiecare cerinţă este specificată o singură dată;
– Schimbabilă: Fiecare cerinţă poate fi schimbată fără a avea un impact major
asupra altor cerinţe.
 CARACTERISTICI DE CALITATE ALE CERINŢELOR
Totodată, este de dorit ca fiecare cerinţă individuală să fie:
• Neambiguă: Fiecare specificare a unei cerinţe trebuie să aibă o singură interpretare şi să
fie descrisă într-o manieră coerentă şi uşor de înţeles.
• Concisă: Fiecare cerinţă trebuie să fie scurtă, folosind un limbaj orientat spre acţiune şi
evitându-se detaliile inutile.
• Măsurabilă: Dacă este necesar, pentru fiecare cerinţă se precizează limite sau valori
măsurabile specifice. Caracteristica este utilă în special pentru cerinţele non-funcţionale.
• Fezabilă: cerinţa poate fi implementată folosind tehnici, tehnologii, instrumente şi resurse
existente, cu ajutorul personalul disponibil şi în limite cunoscute de cost şi timp.
• Testabilă: Din perspectiva costurilor, există o modalitate acceptabilă de a stabili dacă
sistemul informatic satisface acea cerinţă.
• Poate fi urmărită: Pentru fiecare cerinţă, pot fi identificate sursa acesteia, precum şi
formele sub care este reprezentată la diferite niveluri de specificare. De asemenea, cerinţa
trebuie specificată într-o manieră care permite urmărirea acesteia în etapele următoare ale
dezvoltării sistemului, şi anume proiectare, implementare şi testare.
ASPECTE PRACTICE

Combinarea tehnicilor
• Datorită limitărilor, o singură tehnică nu poate fi suficientă
• Sunt necesare atât identificarea pornind de la artefacte, cât și identificarea
pornind de la beneficiar
• Exemple:
– Interviuri + observații directe + prototipizarea
– Rapid Application Development: sesiuni JAD + prototip evolutive
Implicare
• Este necesară implicarea activă a beneficiarului, deoarece:
✓ Cerințele se schimbă
✓ Obținem feedback în mod frecvent
✓ Rezolvăm aspecte neînțelese
✓ Încercăm să eliminăm ambiguități
NU PIERDEȚI DIN VEDERE!!

➢ Analiza riscurilor - beneficiarii pot vorbi despre soluții care nu sunt fezabile
datorită:

▪ Mediului

▪ Bugetului

▪ Tehnologiei

➢ Cere sunt cerințele reale ale clientului

➢ Prioritizarea cerințelor

➢ Întotdeauna fii pregătit pentru schimbare

 LIMBAJE PENTRU MODELAREA INFORMAŢIONALĂ

Cuprins

✓ Modelarea în realizarea sistemelor informatice

✓ Limbaje pentru modelarea informaţională
✓ Categorii de limbaje pentru modelarea informaţională
✓ Limbajul UML
MODELAREA ÎN REALIZAREA SISTEMELOR INFORMATICE

• Modelarea - una dintre cele mai importante tehnici de

concepere a sistemelor informatice.
• Model – abstractizare a unei părţi a realităţii înconjurătoare
• Trăsăturile caracteristice ale modelării:
– simplificarea,
– subordonarea la un scop,
– reprezentarea unei realităţi,
– divizarea,
– ierarhizarea
– comunicarea.
MODELAREA ÎN REALIZAREA SISTEMELOR INFORMATICE

• Analiza şi proiectarea orientată-obiect foloseşte trei tipuri diferite

de modele pentru descrierea unui sistem informatic:
➢modelul static care descrie obiectele si relaţiile lor în sistem;
➢modelul dinamic ce descrie interacţiunile între obiecte în cadrul
sistemului ;
➢modelul funcţional care descrie transformarea valorii datelor în
sistem.
LIMBAJE PENTRU MODELAREA INFORMAŢIONALĂ

• La modul general, limbajele pentru modelarea informaţională

fac posibilă descrierea concisă şi exactă a proprietăţilor
sistemelor la diferite nivele de abstractizare.
• Sunt o parte integrantă a procesului de dezvoltare a sistemelor
informatice în cadrul căruia pot fi folosite pentru:
– a face legătura între etapa de analiză a cerinţelor şi cea de
implementare;
– a verifica proprietăţile critice ale unor sisteme;
– a ajuta la generarea automată de cod şi de cazuri de test.
CATEGORII DE LIMBAJE PENTRU MODELAREA
INFORMAŢIONALĂ
În funcţie de nivelul de formalizare pe care îl impun, limbajele
pentru modelarea informaţională se împart în:
➢ Limbaje informale
➢ Limbaje semi-formale
➢ Limbaje formale
 LIMBAJUL UML
• Limbajul standardizat UML (Unified Modeling Language) a apărut
din necesitatea unei standardizări a tipologiei, semanticii şi a
reprezentării rezultatelor.
• În prezent, UML este un standard de modelare recunoscut de catre
OMG (Object Management Group), standardizarea fiind realizată în
noiembrie 1997, iar până în prezent realizându-se o perfecţionare
continuă a acestuia.
• UML poate fi definit ca fiind un limbaj de vizualizare, specificare,
construire si documentare a modelelor. Valoarea lui constă în faptul
că este un standard deschis, realizează întreg ciclul de dezvoltare al
software-ului, acoperă multe tipuri de aplicaţii, este bazat pe marea
experienţă a celor care l-au realizat şi poate fi implementat de multe
produse de tip CASE.
 LIMBAJUL UML
• UML are notaţii standard şi semantică adecvată modelării
sistemelor orientate obiect.
• Odată cu apariţia acestui limbaj, proiectanţii de sisteme pot
înţelege mai uşor documentaţiile de sistem.
• Înaintea acestei standardizări, un proiect orientat-obiect putea fi
descris folosind una din multele metode orientate-obiect
disponibile, iar dacă era necesară o revizuire, se pierdea un timp
important cu analiza notaţiilor şi semanticii metodei folosite,
înainte de a începe logica proiectării.
ISTORIA UML

2017 UML 2.5.1

 ELEMENTELE DE BAZĂ ALE UML
1. Metamodel pentru modelarea orientată obiect
– Set coerent de definiţii ale unor concepte şi a relaţiilor dintre ele;
– Se defineşte, folosind o sintaxă precisă, fiecare element utilizat în
modelare (exemplu: definirea unei clase);
– Limbaj suport pentru transmiterea modelelor vizuale între diferite
instrumente;
– Are o arhitectură pe patru niveluri.
Strat Descriere Exemplu

meta-metamodel Defineşte limbajul pentru Concepte abstracte din care este

specificarearea metamodelelor. derivat metamodelul.

metamodel Defineşte limbajul pentru Concepte: Clasă, Atribut,

specificarea modelului. Operaţie, Componentă

model Defineşte limbajul folosit pentru Concepte: Student, Materie,

descrierea domeniului analizat. Client, Produs, Comandă

obiectele Definesc informaţii despre obiectele Exemple: Student #3456,

utilizatorului domeniului analizat. Materia #0512
 ELEMENTELE DE BAZĂ ALE UML
2. Tipuri de diagrame
 ELEMENTELE DE BAZĂ ALE UML
3. Mecanisme de extensie

– Stereotipurile caracterizează un element din model sau o relaţie între

elemente (există sterotipuri predefinite).

– Comentariile (notele) descriu suplimentar un element din model.

– Contrângerile limitează utilizarea unui element din model.

– Valori etichetate reprezintă atribute definite pentru un stereotip.

– Profilele personalizează metamodelul prin construcţii care sunt

specifice unui anumit domeniu, platformă sau metodă de dezvoltare.
 MODELAREA CU AJUTORUL DIAGRAMELOR UML

• Modelarea proceselor de afaceri se realizează folosind diagrama

cazurilor de utilizare. Această diagramă dirijează întreg procesul de
dezvoltare a sistemului în cazul metodelor orientate pe cazuri de
utilizare.

• Modelarea structurii statice se face cu ajutorul diagramei claselor

(pentru modelarea structurii statice a claselor sistemului) şi
diagramei obiectelor (pentru modelarea structurii statice a obiectelor
sistemului). Diagrama pachetelor este un mijloc de grupare a
elementelor diagramelor în pachete.
 MODELAREA CU AJUTORUL DIAGRAMELOR UML
• Modelarea dinamicii este realizată utilizând diagrame de interacţiune şi
diagrame care descriu comportamentul. UML utilizează două diagrame
de interacţiune, una pentru modelarea circuitului mesajelor între obiecte,
numită diagrama de secvenţă şi alta, pentru modelarea interacţiunilor
între obiecte, denumită diagrama de comunicare. Ca diagrame ce
descriu comportamentul, se utilizează diagrama de stare pentru
modelarea comportamentului obiectelor din sistem şi respectiv
diagrama de activitate pentru modelarea comportamentului cazurilor de
utilizare, obiectelor sau a operaţiilor.

• Modelarea implementării se face cu ajutorul a două diagrame. Modelarea

componentelor se realizează utilizând diagrama componentelor, iar
modelarea distribuirii sistemului se obţine folosind diagrama de
desfăşurare.
CURSUL 3...

• Diagrama Cazurilor de Utilizare

• Instrumente CASE

51
 ACADEMIA DE STUDII ECONOMICE BUCUREŞTI
FACULTATEA DE CIBERNETICĂ, STATISTICĂ ŞI INFORMATICĂ ECONOMICĂ

P RO I E C TA R E A S I S T E M E LO R
I N F O R M AT I C E

-CURS 3-

BUCUREȘTI
2020-2021
Diagrama de Modelarea
cazuri de utilizare funcțională
Cuprins

▪ Introducere
▪ Cazuri de utilizare
▪ Actori
▪ Relații între cazuri de utilizare și actori
▪ Relații între cazuri de utilizare
▪ Relații între actori
▪ Descrierea textuală a unui caz de utilizare
▪ Bune practici
▪ Erori frecvente
▪ Rezumat notații
Introducere

▪ Cazul de utilizare reprezintă un concept fundamental al multor

metodologii de dezvoltare orientate-obiect.
Diagramele de cazuri de utilizare:
▪ Au rolul de a reprezenta într-o formǎ graficǎ funcţionalitǎţile pe care
trebuie sǎ le îndeplineascǎ sistemul informatic în faza sa finalǎ.
▪ Exprimă așteptările clienților/beneficiarilor:
▪ esențial pentru o proiectare detaliată
▪ Sunt folosite în întreg procesul de analiză și proiectare.
▪ Modelul realizat de diagramele de cazuri de utilizare alǎturi de
documentele de descriere succintǎ a fiecǎrui caz de utilizare identificat
poartǎ numele de model al cerinţelor.
Introducere

▪ Diagramele de cazuri de utilizare sunt formate din actori şi cazuri de

utilizare, pe de o parte, şi relaţiile între acestea, pe de altă parte.
▪ Putem folosi diagrama de cazuri de utilizare pentru a răspunde la
următoarele întrebări:
▪ Ce este descris? (Sistemul)
▪ Cine interacționează cu sistemul? (Actorii)
▪ Ce pot face actorii? (Cazuri de utilizare)
Exemplu: Sistemul de administrare a studenților

▪ Sistem
(Ce este descris?)
▪ Sistemul de administrare a studenților

▪ Actori
(Cine interacționează cu sistemul?)
▪ Profesorul

▪ Cazuri de utilizare
(Ce pot face actorii?)
▪ Interoghează date student
▪ Emite certificat
▪ Anunță examen
Caz de utilizare

▪ “Specifică un set de acţiuni executate de către un sistem sau un subiect

şi care conduc la un anumit rezultat. Rezultatul, în mod normal, este
important pentru un actor sau un beneficiar. “ (OMG)
▪ Oferă beneficii tangibile pentru unul sau mai mulți actori care comunică
cu acest caz de utilizare.
▪ Derivă din cerințele indentificate de la clienți.
▪ Mulțimea tuturor cazurilor de utilizare descrie funcționalitățile pe care
sistemul trebuie să le ofere.
▪ Documentează funcționalitățile pe care le oferă acel sistem.
▪ Notații alternative:
Actor (1/3)

▪ Actorii interacționeză cu sistemul:

▪ prin folosirea cazurilor de utilizare, spre exemplu, actorii inițiază execuția
unui caz de utilizare
▪ find folosiți de către cazurile de utilizare, spre exemplu, actorii oferă
funcționalități pentru execuția unui caz de utilizare
▪ Actorii reprezintă roluri pe care le adoptă utilizatorii.
▪ Anumiți utilizatori pot juca mai multe roluri în același timp.
▪ Actorii nu reprezintă o parte din sistem, ei se găsesc în afara granițelor
sistemului.
▪ Notații alternative:
Actor (2/3)

▪ De obicei datele utilizatorului sunt administrate în cadrul sistemului.

Aceste date sunt modelate sub forma obiectelor și claselor. Exemplu:
actor Asistent
▪ Actorul Asistent interacționează cu sistemul Activitate Seminar
prin utilizarea acestuia.
▪ Clasa Asistent descrie obiectele care reprezintă datele utilizatorului
(spre exemplu, nume, poziție etc.).
Actor (3/3)

▪ Umani
▪ Exemple: Student, Profesor
▪ Non-umani
▪ Exemple: Server E-Mail, ....
▪ Primar: este principalul beneficiar al execuției unui caz de utilizare
▪ Secundar: nu primește niciun beneficiu direct
▪ Activ: inițiază execuția unui caz de utilizare
▪ Pasiv: oferă funcționalitate pentru execuția unui caz de utilizare

▪ Exemplu:
Uman Uman
Primar Secundar
Activ Activ

Non-uman Uman
Secundar Primar
Pasiv Activ 8
Relații între cazuri de utilizare și actori

▪ Asocierile simple sunt folosite pentru a conecta un actor cu un caz de

utilizare. Aceasta reprezintă o cale de comunicare între cei doi.
▪ Fiecare actor trebuie să comunice cu cel puțin un caz de utilizare.
▪ Asocierea este întotdeauna binară.
▪ Pot fi specificate multiplicități. Multiplicitatea mai mare decât unu la
capătul:
▪ corespunzător CU  actorul este implicat în mai multe cazuri de utilizare
de acel tip şi poate iniţia cazuri de utilizare: în paralel (concurent), la
diferite momente de timp sau mutual exclusiv în timp.
▪ corespunzător actorului  mai multe instanţe ale actorului sunt implicate
în iniţierea cazului de utilizare putând realiza acţiuni simultane sau
succesive.
Relații între cazuri de utilizare
Relația de includere

▪ Comportamentul unui unui caz de utilizare (cazul de utilizare inclus)

este integrat în comportamentul altui caz de utilizare (cazul de utilizare
de bază).
▪ Cazul de utilizare care îl include pe un altul nu este complet.
Caz de utilizare de bază
cere comportamentului cazului de utilizare inclus
să îi permită să includă funcționalitatea sa

Cazul de utilizare inclus

este independent din punct de vedere al execuției
Relații între cazuri de utilizare
Relația de extindere

▪ Comportamentul unui caz de utilizare (cel care extinde ) poate fi

integrat în comportamentul altui caz de utilizare (cazul de utilizare de
bază), dar acest lucru nu este obligatoriu.
▪ Ambele cazuri de utilizare pot fi executate în mod independent.

Caz de utilizare de bază

Caz de utilizare care extinde

▪ A decide dacă B este executat.

▪ Punctele de extindere definesc punctul în care comportamentul este
integrat.
▪ Condițiile definesc care sunt circumstanțele în care comportamentul
este integrat.
Relații între cazuri de utilizare
Relația de extindere: puncte de extindere

▪ Punctele de extindere sunt scrise direct în cazul de utilizare.

▪ Este permisă specificarea mai multor puncte de extindere.
Relații între cazuri de utilizare
Relația de generalizare

▪ Cazul de utilizare A generalizează cazul de utilizare B.

▪ B moștenește comportamentul lui A și îl
poate extinde sau suprascrie.
▪ B moștenește și toate relațiile lui A. Caz de utilizare
de bază
▪ B adoptă funcționalitățile de bază ale lui A și
Sub caz
decide ce părți din A execută sau modifică. de utilizare
▪ A poate fi etichetat ca{abstract}
▪ Nu poate fi executat în mod direct
▪ Numai B este executabil
Relații între actori
Relația de generalizare între actori

▪ Actorul A moștenește de la actorul B.

▪ A poate comunica cu X și Y.
Super-actor
▪ B poate comunica doar cu Y.
▪ Este permisă moștenirea multiplă. Sub-actor

▪ Pot exista actori abstracți.

Profesorul ȘI Asistentul sunt necesari Profesorul SAU Asistentul sunt necesari

pentru execuția Interoghează date student pentru execuția Interoghează date student
Descrierea sub formă de șablon a unui caz de utilizare
Element al cazului de Descriere
utilizare
Cod Un identificator unic asociat cazului de utilizare
Stare Stadiul de finalizare în care se găseşte, de exemplu: schiţă, finalizat sau aprobat

Scop Sistemul (parte a sistemului) sau aplicaţia căreia îi aparţine

Nume Numele cazului de utilizare, cât mai scurt şi reprezentativ
Actor principal Beneficiarul care iniţiază cazul de utilizare şi care urmăreşte un anumit scop

Descriere Prezentare scurtă, in text liber, a cazului de utilizare

Precondiţii Ce condiţii trebuie satisfăcute pentru ca scenariul să poată începe
Postcondiţii Ce condiţii trebuie îndeplinite pentru a garanta un final reuşit al scenariului

Posibile erori Erori relevante pentru domeniul problemei

Starea sistemului în În ce stare se găsește sistemul după apariția erorii

caz de eroare
Declanşator Un eveniment sau o succesiune de evenimente care iniţiază cazul de utilizare

Flux de bază Descrie înşiruirea evenimentelor atunci când totul se petrece conform unui
scenariu prestabilit; nu există excepţii sau erori
Fluxuri alternative Cele mai semnificative alternative şi excepţii ale scenariului de bază

Relaţii Ce relaţii are cu alte cazuri de utilizare (de tipul include sau extend)15
Descrierea unui caz de utilizare - Exemplu
Element al cazului de Descriere
utilizare
Cod CU01
Stare Schiţă
Scop Gestiunea sălilor pentru desfășurarea activităților universitare
Nume Rezerva sala
Actor principal Angajat
Descriere Angajatul rezervă o sală a universității pentru un eveniment
Precondiţii Angajatul este autorizat să rezerve săli
Postcondiţii Sala este rezervată
Declanşator Angajatul solicită rezervarea unei săli
Posibile erori Nu există sală liberă.
Starea sistemului în caz de eroare Angajatul nu a rezervat sala.
Flux de bază 1. Angajatul se autentifică în sistem.
2. Angajatul selectează sala.
3. Angajatul selectează data și ora.
4. Sistemul confirmă că sala este liberă. [Curs alternativ A: Sala
nu este liberă]
5. Angajatul confirmă rezervarea.
Fluxuri alternative A: 1. Sistemul propune săli alternative.
2. Angajatul selectează o sală alternativă și confirmă rezervarea.
16
Relaţii Extinde cazul de utilizare CU06 Anunta curs.
Bune practici
«include»

Standard UML Bune practici

Bune practici
«extend»

Standard UML Bune practici

Bune practici
Identificarea actorilor

▪ Cine folosește principalele cazuri de utilizare?

▪ Cine are nevoie de suport pentru munca lor zilnică?
▪ Cine este responsabil pentru administrarea sistemului?
▪ Care sunt dispozitivele externe/sistemele (software) cu care sistemul
trebuie să comunice?
▪ Cine este interesat de rezultatele oferite de sistem?
Identificarea cazurilor de utilizare
▪ Care sunt cele mai importante activități pe care trebuie să le realizeze
un actor?
▪ Dorește un actor să interogheze sau să modifice informațiile conținute
în sistem?
▪ Informează un actor sistemul despre schimbările din alte sisteme?
▪ Ar trebui ca un actor să fie informat despre rezultatele neașteptate
apărute în sistem?
Bune practici
Erori de evitat - 1

▪ Cazurile de utilizare nu modelează procese sau fluxuri de lucru!

Bune practici
Erori de evitat - 2

▪ Actorii nu sunt parte a sistemului, ce aceea trebuie poziționați în afara

granițelor!
Bune practici
Erori de evitat - 3

▪ Cazul de utilizare Distribuie informare necesită DOAR un

actor Asistent SAU un actor Profesor pentru a se executa

✓
Bune practici
Erori de evitat - 4

▪ Mai multe cazuri de utilizare mici care au același obiectiv pot fi grupate
într-un singur caz de utilizare.

✓
Bune practici
Erori de evitat - 5

▪ Pașii de executat sunt părți ale cazului de utilizare, cazurile de utilizare

NU trebuie descompuse funcțional

✓
Notații - 1

Nume Notație Descriere

Granițele dintre sistem și

Sistem
utilizatorii acestuia

Caz de utilizare Unitate funcțională a sistemului

Actor Rol al utilizatorilor în sistem

Notații - 2

Nume Notație Descriere

Relație între cazuri de utilizare și

Asociere
actori

Relație de moștenire între actori

Generalizare
sau cazuri de utilizare

Relația de B extinde A: utilizare opțională a

extindere CU B de către CU A

Relația de A include B: necesită folosirea CU

includere B de către CU A
Recapitulare

1. Ce descrie diagrama cazurilor de utilizare?

2. Ce relații există între actori și cazuri de utilizare?
3. Poate un actor să nu comunica cu niciun caz de utilizare? Dar cu mai
multe cazuri de utilizare?
4. Ce semnifică într-o relație de asociere o multiplicitate mai mare decât
unu la capătul actorului?
5. Ce reprezintă un actor secundar? Dar un actor activ?
6. Pentru relația de includere, cazul de utilizare care îl include pe altul
este complet? Argumentați.
7. Explicați relația de extindere dintre cazurile de utilizare.
8. Ce este un actor abstract și cum poate fi folosit? Exemplificați.
9. Cum reprezentăm situația în care mai mulți actori sunt necesari
pentru realizarea unui caz de utilizare?
Instrumente
CASE
Cuprins

▪ Instrumente CASE: concepte, obiective şi facilităţi

▪ Clasificarea instrumentelor CASE
▪ Arhitectura mediului CASE
▪ Visual Paradigm
Instrumente CASE

❑ CASE : Computer Aided Software Engineering

❑ Instrumentele CASE - instrumentele integrate care susțin activitățile
front-end și back-end legate de dezvoltarea sistemelor informatice
❑ Utilitate de ordin:
❑cantitativ
❑calitativ
❑ Instrumentele CASE reduc substanţial sau elimină multe din
problemele de proiectare şi dezvoltare a aplicaţiilor informatice.
Obiective

❑ Obiectivul principal al tehnologiei CASE:

de a îmbunătăți productivitatea și calitatea sistemelor
rezultate, asistând echipa de dezvoltare pe parcursul
diferitelor etape ale procesului de realizare, de la identificarea
cerințelor funcționale și nefuncționale ale sistemului până la
proiectarea și implementarea acestuia, luând în considerare
toate caracteristicile tehnice și operaționale relevante.
Obiective

❑ specificarea corectă şi completă a cerinţelor sistemului;

❑ reducerea timpului şi costului de proiectare şi dezvoltare;

❑ integrarea activităţilor de proiectare şi dezvoltare prin

utilizarea unor metodologii/metode comune;

❑ standardizarea procesului de proiectare şi dezvoltare a

sistemelor informatice;

❑ simplificarea şi îmbunătăţirea procesului de testare;

Obiective

❑ simplificarea etapei de întreţinere a sistemelor informatice;

❑ realizarea unor documentaţii de calitate;

❑ îmbunătăţirea managementului proiectelor;

❑ reutilizarea modulelor aplicaţiilor şi a documentaţiei;

❑ îmbunătăţirea portabilităţii aplicaţiilor;

❑ asigurarea acurateţei componentelor construite

Facilităţi
❑ suport pentru conducerea proiectului. Deosebit de utile sunt instrumentele de
planificare şi estimare a timpului şi resurselor necesare realizării sistemului,
precum şi gestiunea versiunilor proiectului;
❑ generarea documentaţiei de realizare a sistemului informatic;
❑ stocarea şi regăsirea datelor din depozitul central de date (repository) prin
utilitare specifice;
❑ verificarea automată a consistenţei şi completitudinii datelor printr-un analizor
ce conţine reguli specifice pentru fiecare metodologie/metodă;
❑ generarea automată a codului de program, pornind de la specificaţiile de
proiectare;
❑ tehnica de inginerie inversă (reverse ingineering) prin care se permite
revenirea dintr-o etapă de realizare a aplicaţiei la o etapă precedentă pentru
eventuale modificări
❑ suport pentru realizarea de prototipuri, prin limbaje de programare de nivel
înalt şi generatoare.
Tipologia instrumentelor CASE

1. După aria de cuprindere a ciclului de realizare a aplicaţiei:

Planificare

Upper CASE
Analiză

Integrated CASE
Proiectare
Implementare

Lower CASE
Testare
Mentenanță
Tipologia instrumentelor CASE

❑ Instrumente CASE front-end (sau upper CASE) care oferă suport

pentru primele etape de realizare a aplicaţiilor informatice (analiza şi
specificarea cerinţelor, proiectarea logică).
❑ Instrumente CASE back-end (sau lower CASE) care oferă suport
pentru ultimele etape de realizare a aplicaţiilor informatice
(proiectarea fizică, elaborarea programelor, testarea, întreţinerea
sistemului).
❑ Instrumente CASE cross life cycle care oferă suport pentru
activităţile ce apar în mai multe etape ale procesului de proiectare şi
dezvoltare a sistemelor informatice (de exemplu, instrumente
utilizate pentru managementul proiectului, generatoare de
documentaţie).
Tipologia instrumentelor CASE

2. După scopul utilizării:

❑ Instrumente CASE pentru construirea diagramelor – componentele
sistemului, fluxurile de date și fluxurile de control între diferitele
componente ale acestuia pot fi reprezentate în formă grafică/

❑ Instrumente CASE pentru managementul proiectului - utilizate pentru

planificarea proiectelor, estimarea costurilor și eforturilor și planificarea
resurselor. Instrumentele de management al proiectelor ajută la
stocarea și partajarea informațiilor despre proiect în timp real în întreaga
organizație.
Tipologia instrumentelor CASE

❑ Instrumentele de documentare generează documentaţie pentru

utilizatorii tehnici și utilizatorii finali. Utilizatorii tehnici sunt specialisti,
membri ai echipei de dezvoltare care utilizează manualule de sistem,
manualule de instruire, manuale de instalare etc. Documentele
utilizatorului final descriu funcționarea și instrucțiunile sistemului, cum ar
fi manualul utilizatorului;
❑ Instrumente CASE pentru analiză - aceste instrumente ajută la
colectarea cerințelor, verifică automat dacă există inconsecvențe,
inexactități în diagrame, redundanțe de date sau omisiuni eronate.
❑ Instrumente CASE pentru proiectare - aceste instrumente îi ajută pe
proiectanții de software să proiecteze structura produsului, care poate fi
descompusă în module mai mici folosind tehnici de rafinare. Aceste
instrumente oferă detalii despre fiecare modul și interconectările dintre
module
Tipologia instrumentelor CASE

❑ Instrumente pentru managementul schimbărilor - automatizează

urmărirea modificărilor, gestionarea fișierelor, gestionarea codului etc
❑ Instrumente de programare - aceste instrumente constau din medii de
programare precum IDE (Integrated Development Environment),
biblioteci și instrumente de simulare. Ele oferă ajutor în construirea
produselor software și includ facilități pentru simulare și testare.
❑ Instrumente de asigurare a calității - asigurarea calității într-o
organizație software monitorizează procesul de inginerie și metodele
adoptate pentru a dezvolta produsul software pentru a asigura
îndeplinirea standardelor organizației. Instrumentele QA constau în
instrumente de configurare și control al modificărilor și instrumente de
testare software.
Tipologia instrumentelor CASE
3. După dimensiunea suportului oferit:
❑ Instrumente CASE propriu-zise ce oferă suport pentru o singură
activitate din cadrul unei etape de realizare a aplicaţiilor (de
exemplu, editoare de diagrame şi text, instrumente pentru analiza
consistenţei şi completitudinii specificaţiilor de sistem, depanatoare
etc.);
❑ Bancurile de lucru CASE (workbenches) care oferă suport pentru o
etapă din ciclul de realizare a aplicaţiei;
❑ Mediile CASE care oferă suport pentru cea mai mare parte (sau
toate) dintre etapele de realizare a sistemului informatic. Din această
categorie fac parte următoarele instrumente: IBM Rational Architect
Cradle/3SL, Corporate Modeler/CASEWise Inc etc.
Arhitectura mediului CASE

Editoare
pentru
Instrumente diagrame
pentru Generatoare
conducerea de rapoarte
proiectului

Utilitare pentru Instrumente

testare si pentru
depanare Depozitul validare
central de
date

Instrumente
Instrumente
pentru
pentru
generarea
inginerie
automata a
inversa
documentatiei
Instrumente
pentru
Utilitare pentru
generarea
transformare
automata a
codului
Arhitectura mediului CASE

▪ Depozitul de date central (nucleul unui mediu I-CASE) stochează

toate obiectele şi informaţiile necesare pentru proiectarea, modelarea şi
generarea aplicaţiilor. Depozitul de date central conţine depozitul de
informaţii (information repository) şi dicţionarul de date. Depozitul de
informaţii conţine informaţiile despre afacerile organizaţiei şi portofoliul ei
de aplicaţii. Dicţionarul de date gestionează şi controlează accesul la
depozitul de informaţii. El stochează descrieri ale datelor şi ale
resurselor de prelucrare a datelor.

▪ Editoarele pentru diagrame permit reprezentarea vizuală a unui sistem

şi a componentelor lui. Diagramele sunt foarte eficace pentru
reprezentarea fluxurilor de procese, a structurilor de date şi a structurilor
de program.
Arhitectura mediului CASE

▪ Utilitarele pentru transformare convertesc elementele obţinute cu

instrumentele de analiză în elemente ale proiectării.

▪ Generatoarele de forme şi rapoarte sunt utilizate pentru a crea,

modifica şi testa prototipurile de forme şi rapoarte şi pentru a
identifica datele care vor fi afişate sau colectate pentru fiecare formă
şi raport

▪ Instrumentele pentru validare/verificare generează rapoarte prin

care se identifică inconsistenţele, redundanţa şi lipsurile din
diagrame, forme şi rapoarte.

▪ Instrumente pentru generarea automată a codului pornind de la

specificaţiile de proiectare conţinute în depozitul de date central
(instrumente pentru generarea obiectelor bazei de date şi a
modulelor aplicaţiei).
Visual Paradigm
Visual Paradigm

1. Se axează pe trei direcţii principale:

Identificarea Construirea de Generarea de cod şi

cerinţelor modele baze de date

2. Asigură interoperabilitatea cu alte instrumente CASE (Visio, Visual

UML, Rational) şi integrarea cu instrumentele IDE de marcă (Net
Beans)
3. Acoperă mare parte a ciclului de viaţă al unui sistem informatic
 Visual Paradigm

Enterprise Professional Standard Modeler Community

Diagrame UML ✓ ✓ ✓ ✓ ✓
Diagrame SysML ✓ ✓ ✓ ✓ ✓

Diagrama EA ✓ ✓ ✓ ✓ ✓

Sabloane predefinite ✓ ✓ ✓ ✓ ✓

Analiză textuală ✓ ✓ ✓ ✓ ✓

Diagrame BPMN ✓ ✓ ✓ ✓

Instrument de machetare ✓ ✓ ✓

Harta Scrum User Story ✓ ✓

Ghid de management al ✓
proiectului
Visual Paradigm

Include modele ale unor limbaje standard

❑ Modelarea UML - Pot fi create toate tipurile de diagrame UML 2.x prin
construirea de modele de cazuri de utilizare, comportamentale, de
interacţiune, structurale, de amplasare, de cazuri de test.

❑ Modelarea BPMN – Pot fi create: diagrame de procese de afaceri,

diagrame de flux de date, diagrame de hărţi de procese, diagrama
lanţului de procese conduse prin evenimente, organigrame. Diagramele
de procese de afaceri pot fi exportate în BPEL.

❑ Modelarea SysML - SysML este un limbaj general pentru ingineria

aplicaţiilor şi sistemelor informatice. VP-UML permite crearea diagramei
de cerinţe specifice limbajului SysML.
Visual Paradigm
Modelarea cerinţelor
Identifică cerinţele prin intermediul a mai multe mecanisme:
❑ Analiza textuală oferă editor de text prin intermediul căruia sunt înregistrate
cerinţele în format textual şi care permite identificarea termenilor sau
obiectelor importante (clase, cazuri de utilitare) pentru descrierea
problemei.
❑ Cardurile CRC conţin informaţii precum descrirea clasei, atributele acesteia
şi responsabilităţile. Au formate proprii de afişare a informaţiilor.
❑ Diagrame de cerinţe SysML pentru a identifica cerinţele funcţionale sau
non-funcţionale ale sistemului.
❑ Editorul de interfeţe utilizator prin intermediul căruia se crează machete ale
ecranelor.
❑ Managementul glosarului de termeni prin care se identifică şi se descrie
vocabularul proiectului.
Visual Paradigm

Modelarea bazelor de date

❑ Se pot crea două tipuri de diagrame pentru modelarea bazelor de date: diagrame
Entitate-Relaţie şi diagrame ORM (pentru a vizualiza maparea dintre modelul de
obiecte şi modelul de date).

❑ Se pot modela nu numai caracteristici ale tabelelor, ci şi proceduri stocate,

declanşatori, secvenţe şi viziuni ale bazei de date într-o diagramă Entitate-
Relaţie.

❑ Diagramele se pot construi de la zero sau prin inginerie inversă plecând de la o

bază de date existentă.

❑ Sincronizare între diagrama de clase şi diagrama Entitate-Relaţie pentru a

asigura consistenţa între cele două modele.

❑ Generarea de cod SQL pornind de la modele.

Visual Paradigm
Generare de cod
❑ Generatoarele de inginerie inversă şi directă oferă suport pentru ingineria
modelelor. Facilitatea Java Round-Trip engineering permite sincronizarea
continuă a codului şi a modelului pentru limbajul Java.
Model Inginerie directă Inginerie inversă
Java x x
C++ x x
XML Schema x x
PHP x x
Python Source x x
Objective-C x x
CORBA IDL Source x x
.NET dll sau fişiere .exe x
CORBA IDL Source x
XML (structure) x
JDBC x
Hibernate x
C# x
VB.NET x
ODL x
ActionScript x
Delphi x
Perl x
Ada95 x
Ruby x
Visual Paradigm

Interoperabilitate
❑ Interoperabilitatea facilitează schimbul de modele cu alte instrumente.

Model Import Export

Telelogic Modeler x
Rational Rose x
ERwin Data Modeler proiect x
Rational Software Architect x
Rational DNX x
NetBeans 6.x UML diagrame x
Visio x
BPEL for Oracle workflow engine x
BPEL for JBoss workflow engine x
Diagram (JPG, PNG, SVG, EMF, PDF) x
Microsoft Excel x x
EMF UML2 model x x
XMI (1.0, 1.2, 2.1) x x
XML (nativ) x x
Microsoft Word pentru modelul CU) x x
Visual Paradigm

Integrarea cu medii IDE

❑ Oferă suport pentru întreg ciclul de dezvoltare a unui sistem informatic
folosind pentru etapa de programare următoarele produse de tip IDE :
▪ Eclipse
▪ NetBeans/Sun ONE
▪ IntelliJ IDEA

Generarea documentaţiei
❑ Documentaţia poate fi partajată şi proiectată împreună cu beneficiarii
sistemului folosind unul dintre formatele: HTML (report generation) ,
HTML (project publisher) , PDF , Word.
 ACADEMIA DE STUDII ECONOMICE BUCUREŞTI
FACULTATEA DE CIBERNETICĂ, STATISTICĂ ŞI INFORMATICĂ ECONOMICĂ

P RO I E C TA R E A S I S T E M E LO R
I N F O R M AT I C E

-CURS 4-

BUCUREȘTI
2020-2021
Diagrama de Modelarea
structurii
clase statice
Sinteză: Analiza orientată obiect a sistemelor informatice
În etapa de analiză a sistemului sunt analizate specificaţiile şi
cazurile de utilizare, identificându-se cele mai importante concepte cu
care lucrează sistemul, împreună cu relaţiile dintre acestea. Se
reprezintă grafic, printr-o diagramă, structura domeniului claselor
pentru sistemul analizat.
1. Se iniţiază reprezentarea diagramei de clase, care va fi finisată şi în
etapele următoare. Diagrama claselor reprezintă grafic structura
statică a sistemului, prin includerea claselor identificate, a pachetelor
şi a relaţiilor dintre acestea. Un pachet poate conţine clase, interfeţe,
componente, noduri, colaborări, cazuri de utilizare, diagrame sau alte
pachete.
2. Se iniţiază construirea diagramei de obiecte care modelează
instanţele elementelor conţinute în diagramele de clase. Aceste
diagrame cuprind un set de obiecte şi relaţiile dintre acestea la un
anumit moment.
Sinteză: Analiza orientată obiect a sistemelor informatice
3. Pentru a evidenţia stările prin care poate trece un obiect sau un
eveniment (mesaje primite, erori, condiţii de realizare) sunt reprezentate
diagramele de stare, care reprezintă ciclul de viaţă al obiectelor,
subsistemelor şi sistemelor. Stările obiectelor se schimbă la
recepţionarea evenimentelor sau semnalelor.
4. Diagrama de activitate este realizază cu scopul de a evidenţia acţiunile şi
rezultatul acestor acţiuni şi pentru a scoate în evidenţă fluxurile de lucru.
5. Pentru a evidenţia interacţiunile dintre obiecte se construiesc diagramele
de interacţiune: diagramele de secvenţă şi, respectiv, diagramele de
comunicare.
▪ Diagramele de secvenţă descriu modul în care interacţionează şi comunică
obiectele, prin focalizare pe mesajele care sunt transmise şi recepţionate.
▪ Diagramele de comunicare permit reprezentarea atât a interacţiunilor, cât şi
a legăturilor dintre un set de obiecte care colaborează. Se utilizează când
este utilă vizualizarea coordonatei spaţiale.
 Modelarea structurii statice. Diagrama de clase

Diagrama de clase este instrumentul principal de analiză şi proiectare

a structurii statice a sistemului.

În ea se precizează structura claselor sistemului, relaţiile între clase şi

structurile de moştenire.

La proiectare se utilizează aceeaşi diagramă şi se modifică pentru a fi

conformă cu detaliile de implementare.
Diagrama de clase

1. Scopul diagramei claselor este de a prezenta natura statică a claselor

punând in evidenţă atributele, operaţiile şi asocierile.

2. Majoritatea instrumentelor de modelare orientate obiect generează

cod sursă din diagrama claselor.

3. Celelalte diagrame UML furnizează diferite puncte de vedere din care

să fie identificate atributele, operaţiile şi asocierile dintre clase. Ele
ajută la validarea diagramei claselor, putând servi la clarificarea unei
probleme specifice.
Definirea unei clase

1. Ansamblu de obiecte care au aceleaşi caracteristici şi contrângeri.

2. Caracteristicile unei clase sunt atributele şi operaţiile.
3. Clasele abstracte nu pot fi instanţiate. Rolul lor este de a permite altor
clase să le moştenească, în vederea reutilizării caracteristicilor.
4. O interfaţă descrie un set de caracteristici şi obligaţii publice.
Specifică, de fapt, un contract. Orice instanţă care implementează
interfaţa trebuie să ofere serviciile furnizate prin contract.
Exemple de clase stereotipe uzuale

▪ entitate (<<entity>>) – o clasă pasivă, care nu iniţiază interacţiuni;

▪ control (<<control>>) – iniţiază interacţiuni, conţine o componentă
tranzacţională şi este separator între entităţi şi limite;
▪ limită (<<boundary>>) – este aflată la periferia sistemului, dar în interiorul
său. Reprezintă limita de legătură cu actorul sau cu alte sisteme
informatice;
▪ enumerare (<<enumeration>>) - este folosită pentru definirea tipurilor de
date ale căror valori sunt enumerate.
▪ primitivă (<<primitive>>) - o formă de clasă care reprezintă tipuri de date
predefinite, cum ar fi tipul Boolean.
Atribute

1. Fiecare atribut este descris cel puţin prin numele său.

2. Este de preferat ca numele atributului să înceapă cu literă mică.
3. Se pot adăuga şi informaţii adiţionale, iar forma generală a unui atribut
este:
[vizibilitate][/]nume[:tip][multiplicitate][=valoare implicită]
[{proprietate}]
 [vizibilitate][/]nume[:tip][multiplicitate][=valoare implicită] [{proprietate}]

Atribute - Vizibilitate

➢ Vizibilitatea poate fi:

▪ + public: poate fi văzută şi folosită de oricine
▪ - private: numai clasa însăşi poate avea acces
▪ # protected: au acces clasa şi subclasele acesteia
▪ ~ package: numai clasele din acelaşi pachet pot avea acces
Persoana

+ nume: String
+ prenume: String
- /dn: Data
# adresa: String[1..*] { unique, ordered}
- cnp: String {readonly}
- parola: Sting =“psw1234”
- cod: int
- nrPersoane: int
 [vizibilitate][/]nume[:tip][multiplicitate][=valoare implicită] [{proprietate}]

Atribute – Atribut derivate și nume

➢ / simbolizează un atribut derivat

➢ acesta se calculează pe baza altor valori și este, de obicei, readonly
➢ numele sunt desemnate prin substantive

Persoana Persoana

+ nume: String + nume: String

+ prenume: String + prenume: String
-/dn: Data -/dn: Data
# adresa: String[1..*] { unique, ordered} # adresa: String[1..*] { unique, ordered}
- cnp: String {readonly} - cnp: String {readonly}
- parola: Sting =“psw1234” - parola: Sting =“psw1234”
- cod: int - cod: int
- nrPersoane: int - nrPersoane: int
 [vizibilitate][/]nume[:tip][multiplicitate][=valoare implicită] [{proprietate}]

Atribute – Tip de date

Tipuri de date
▪ Tipuri de date primitive
• Predefinite: Boolean, Integer, String
• Definite de utilizator: «primitive»
• Tipuri de date compozite: «datatype»
▪ Enumerări: «enumeration»

<<primitive>> <<datatype>> <<enumeration>>

Float Data TitluAcademic
round(): void zi licenta
luna masterat
an doctorat
 [vizibilitate][/]nume[:tip][multiplicitate][=valoare implicită] [{proprietate}]

Atribute -Multiplicitate

1. UML permite specificare multiplicităţilor pentru atribute, atunci când

dorim să definim mai mult de o valoare pentru un atribut. Au următoarea
semnificaţie:
Multiplicitate Sens
1 Exact 1 (implicit)
2 Exact 2
1..4 De la 1 la 4 (inclusiv)
3, 5 3 sau 5
1..* Cel puţin unul sau mai mulţi Persoana
* Nelimitat (inclusiv 0)
+ nume: String
0..1 0 sau 1 + prenume: String
-/dn: Data
# adresa: String[1..*] { unique, ordered}
- cnp: String {readonly}
- parola: Sting =“psw1234”
- cod: int
- nrPersoane: int
 [vizibilitate][/]nume[:tip][multiplicitate][=valoare implicită] [{proprietate}]

Atribute - Proprietate
 Proprietate indică o proprietate suplimentară care se aplică atributului:
 {readonly}: atributul poate fi citit, dar nu modificat

 {ordered}, {unordered}: o mulţime ordonată sau neordonată

 {unique}, {non-unique}: mulţimea poate conţine sau nu elemente identice

Persoana

+ nume: String
+ prenume: String
-/dn: Data
# adresa: String[1..*] { unique, ordered}
- cnp: String {readonly}
- parola: Sting =“psw1234”
- cod: int
- nrPersoane: int
 Operaţii

1. Forma generală a unei operaţii este:

[vizibilitate] nume ([direcţie] lista parametri) [:tip returnat] [{proprietate}]

1. Vizibilitatea – aceeaşi ca şi la clase

2. Direcţie - 'in' | 'out' | 'inout' | 'return'
3. Tip returnat – dacă operaţia returnează ceva, adică este o funcţie
4. Un exemplu de proprietate a unei operaţii: {query} - nu are efecte secundare, nu
schimbă starea unui obiect sau a altor obiecte, exemplu operaţiile de tip “get”.
Exemple de atribute: Exemple de operaţii:
• - varsta: Integer {varsta>18} • + setVarsta (out varsta: Integer)
• # nume:String[1..2]=“Ioana” • + getVarsta(in Id:String): Integer {query}
• ~ Id:String {unique} • - schimbaNume(inout nume:String)
• / sumaTotala:Real=0
Constrângeri

1. O constrângere este o expresie care restricţionează un anumit

element al diagramei de clase.
2. Aceasta poate fi o expresie formală (scrisă în Object Constraint
Language - OCL) sau o formulare semi-formală sau informală.
3. Acestea sunt reprezentate între acolade.
4. Pot fi scrise imediat după definirea elementului sau ca un comentariu.
5. O constrângere poate avea şi un nume, astfel:
{nume : expresie booleană }

Exemple de constrângeri OCL:

context Organizatie
inv: self. departamente→isUnique (nume)
inv: departamante.angajati→isUnique (cod)
Relaţii între clase

Relaţia de asociere implică stabilirea unei relaţii între clase.

1. Este caracterizată prin:
▪ denumire (opţională)
▪ multiplicităţi – se trec la cele 2 capete ale asocierii;
▪ roluri ale asocierii: se trec la fiecare capăt al asocierii şi conţin o
descriere scurtă şi reprezentativă (1 – 2 substantive)
▪ direcţie de navigare

1. Tipuri de asocieri:
➢unare
➢binare
➢n-are
Asocierea binară

1. Conectează între ele instanțele a două clase.

Navigare Nume asociere Direcție de citire

Multiplicitate

tineCursPentru
* *
+cadruDidactic

Non-navigare

Vizibilitate Rol
Asocierea binară - Navigare

1. Navigare: un obiect cunoaște obiectul său partener și poate

accesa atributele și operațiile vizibile ale acestuia
▪ Indicată prin intermediul unui arc
2. Non-navigare
▪ Indicată prin cruce
3. Exemple:
▪ A poate accesa atributele și operațiile
vizibile ale lui B
▪ B nu poate accesa niciun atribut și
operație a lui A
4. Navigare nedefinită
▪ Navigarea implicită este bidirecțională
Navigare- Standard UML vs. bune practici

Standard UML Bune practici

Asocierea – Multiplicitate și rol

1. Multiplicitate: numărul de obiecte alei unei clase care pot fi

asociate cu exact un obiect al clasei de la capătul opus al asocierii

2. Rol: descrie modul în care un obiect este implicat într-o relație de

asociere
Asocierea binară – constrângere xor

1. Constrângere “sau exclusiv”

2. Un obiect al clasei A se poate asocia cu un obiect al clasei B sau
cu un obiect al clasei C,dar nu cu amândouă în același timp.
 Asocierea n-ară
 Mai mult de două obiecte partenere sunt implicate într-o relație.
 Nu există direcții de navigare
 (Student, Examen) → (Profesor)
Un student susține un examen cu unul sau niciun profesor
 (Examen, Profesor) → (Student)
Un examen cu un profesor poate fi susținut de oricâți studenți
 (Student, Profesor) → (Examen)
 Un student poate fi evaluat de un profesor pentru oricâte
examene

Asociere ternară
 Asociere modelată ca o clasă
 Asignează atribute unei relații între clase și nu clasei în sine.
 Necesară atunci când modelăm asocieri mulți-la-mulți

 Pentru asocierile unu-la-unu sau unu-la-mulți este posibilă, dar nu

necesară
Asociere modelată ca o clasă vs. clasă

Un Student se poate înscrie la Un Student se poate înscrie la

un anumit program de studiu o un anumit program de studiu de
singură dată mai multe ori
 Asociere modelată ca o clasă – unique/ non-unique

 Implicit: fără duplicate  Non-unique: cu

duplicate

Unui student i se permite să fie evaluat Unui student i se permit mai multe
pentru un examen o singură dată. evaluări pentru un examen.
 Agregarea

• Este o formă specială de asociere binară

• Reprezintă o relaţie de tip parte/întreg
• Este folosită pentru a arăta că o clasă este parte a altei clase
• Proprietăți ale agregării:
• Tranzitivă: dacă B este parte din A și C este parte din B,
atunci C este și parte din A.
• Asimetrică: nu este posibil ca A să fie parte din B și B să fie
parte din A, în același timp
• Poate fi de doua tipuri:
• Agregare partajată (agregare)
• Agregare compusă (compunere)
Agregarea partajată

• Exprimă o formă slabă de apartenență a părții la întreg

• Părțile pot exista independent de întreg
• Multiplicitatea la capătul agregat poate fi > 1
• Aceleaşi părţi partajate pot fi incluse simultan în mai multe clase
întreg
• Dacă se şterge clasa întreg, clasele parte vor exista în continuare
• Sintaxa: se reprezintă sub forma unui romb gol plasat la capătul
clasei întreg
• Exemplu: Disciplina este parte a unui program de studiu
Agregarea compusă
• Exprimă o formă puternică de apartenență a părții la întreg
• Multiplicitatea la capătul agregat este maxim 1
✓ Aceleaşi părţi partajate nu pot fi incluse simultan în mai multe
clase întreg
• Dacă se şterge clasa întreg, se vor șterge și clasele parte
• Sintaxa: se reprezintă sub forma unui romb plin plasat la capătul
clasei întreg
• Example: Proiectorul este parte a unei săli, iar sala este parte a
unei clădiri

Dacă este ștearsă Clădirea,

se va șterge și Sala
Relații de asociere

Asociere
Obiectele ştiu unele de existenţa celorlalte şi pot lucra împreună.

Agregare
1. Protejează integritatea configuraţiei.
2. Funcţionează ca un tot unitar.
3. Control prin intermediul unui singur obiect.

Compunere
Fiecare parte poate fi membră a unui singur obiect agregat.

Relaţii între asociere, agregare şi compunere

 Generalizarea

• Caracteristicile (atributele și operațiile),

asocierile și agregările care sunt specifice
pentru o clasă generală (superclasă) sunt
transferate subclaselor sale.
• Se mai numeşte informal şi relaţie de
genul “este un tip de”.
• Se reprezintă sub forma unui triunghi gol
plasat la capătul superclasei.
• Clasele abstracte sunt intens utilizate în
contextul generalizării.
• Este permisă moştenirea multiplă.
• Subclasele își pot defini propriile
caracterstici, atribute și agregări.
 În modelarea structurată

1. Pentru identificarea entităţilor din

domeniul analizat, în analiza
structurată se folosea diagrama
entitate asociere
2. Acesta nu este inclusă în UML,
dar este folosită pe larg de
analişti în proiectarea bazelor de
date şi de administratorii de baze
de date în implementarea bazei
de date
3. Nu poate fi folosită pentru a
reprezenta relaţii de generalizare
sau relaţii parte-intreg
 Tehnici de identificare a claselor

a) Tehnica brainstorming – se utilizează o lista de control cu toate

tipurile de entităţi care apar în mod frecvent şi se realizează şedinţe
de brainstorming pentru a identifica clasele domeniului pentru fiecare
dintre tipurile respective
b) Tehnica substantivelor – se identifică toate substantivele care apar
în descrierea sistemului şi se hotărăşte dacă substantivul este o
clasă a domeniului, un atribut sau un element neimportant
 a. Tehnica de brainstorming

1. Avem elemente de genul…

Entitati

Unitati
Tangibile Roluri Dispozitive Locatii Evenimente
organizatorice

Avion Angajat Divizie Senzor Depozit Zbor

Carte Doctor Departament Controler Fabrica Logon
Autovehicul Pacient Birou Imprimanta Magazin Logoff
Documet Client Sectie Timer Sucursal Comanda
Formular Utilizator Grup de lucru Scaner a Contract
Administr Sortator Desktop Achizitie
ator de Plata
sistem
 b. Tehnica substantivelor

1. Se identifică toate substantivele pe baza cazurilor de utilizare, actorilor şi

altor informaţii despre sistem
2. Se preiau informaţiile necesare din sistemele, procedurile, formularele şi
rapoartele existente
3. Se rafinează lista de substantive
▪ Aparţine ariei de cuprindere a sistemului analizat?
▪ Este nevoie să pastrăm mai mult de un astfel de element?
▪ Este un sinonim pentru un element deja identificat?
▪ Este un atribut al altui element inregistrat?
▪ Este doar un output al sistemului obţinut pe baza unui alt element deja
identificat?
▪ Este doar un input care rezultă din inregistrarea altui element identificat?
4. Se crează o listă principală de substantive şi se notează care trebuie
inclus/exclus/ discutat
5. Se prezintă lista utilizatorilor, beneficiarilor, membrilor echipei spre
validare
 Diagama claselor
Linie Aeriana
+DisponibilitateRezervare : boolean
+FurnizareDetaliiZbor() : void
+ConfirmareRezervare() : Boolean
numar zbor
1 Rezervare Zbor
programeaza
1..*
Zbor
+Destinatie : char
+Plecare : char
+DataZbor : char
+OraZbor : char
+Pret : int
+NumarZbor : int
Pasager
1 1..* Vanzator 1..* 1..* -NumePasager : char
rezerva zbor
numar rezervare este rezervat cu #AdresaPasager : char
+RezervaZbor() -CNP : unsigned long
+VerificaDisponibilitate() +SolicitaZbor() : void
+FacePlata() : void
Bilet
NumePasager : char NumeCompanie : char
NumarZbor : int PretBilet : int
NumarRezervare : int DataZbor : char
OraZbor : char
NumarZbor : int
NumarBilet : char
Agentie Voiaj Agentie Linie Aeriana
-NumeAgentie : char -LinieAeriana : char
-AdresaAgentie : char +AdresaLinieAeriana : char
Figura 7.45. Diagrama claselor în etapa de analiză
Tehnica fişelor CRC

• Este utilizată uneori ca extensie a UML-ului pentru o analiză

orientată pe responsabilităţi.
• Definiţiile claselor sunt rafinate pe baza responsabilităţilor lor şi a
altor clase cu care acestea colaborează pentru a îndeplini aceste
responsabilităţi.
• Pentru fiecare clasă se întocmeşte o fişă pe care se evidenţiază
responsabilităţile clasei şi care sunt clasele cu care ea colaborează
pentru a îndeplini aceste responsabilităţi.
• Aceste informaţii se transpun direct într-o diagramă a claselor,
responsabilităţile corespund metodelor, iar colaborările corespund
asocierilor dintre clase.
 Tehnica fişelor CRC

Pentru a afla preţul trebuie

Pasager Bilet
să colaborez cu pasagerul
şi compania aeriană
Superclasă: <none> Superclasă: <none>
Subclase: <none> Subclase: <none>
Responsabilităţi Colaboratori Responsabilităţi Colaboratori
Plata biletului Vanzator_bilet Află pretul Companie, Pasager
Solicitare zbor Vanzator_bilet

Companie Zbor

Superclasă: <none> Superclasă: <none>

Subclase: <none> Subclase: <none>
Responsabilităţi Colaboratori Responsabilităţi Colaboratori
Furnizează detalii zbor Vanzator_bilet, Zbor Locuri disponibile <none>
Confirmă rezervarea Vanzator_bilet, Zbor

Vanzator_bilet

Superclasă: <none>
Subclase: <none>
Responsabilităţi Colaboratori
Verifică disponibilitatea Companie, Zbor
Rezervă zbor Companie, Pasager
Notații - 1

Nume Notație Descriere

Descrie structura și
Clasă comportamentul unui set de
obiecte

Clasă abstractă Clasă care nu poate fi instanțiată

Relații între clase:

navigare nespecificată,
Asociere
navigare în ambele direcții,
non-navigare într-o direcție
39
Notații - 2

Nume Notație Descriere

Asociere n-ară Relație între n clase (aici trei clase)

Asociere
Descriere mai detaliată a unei
modelată ca o
asocieri
clasă

Un obiect A is este într-o relație cu

Relație xor un obiect B sau cu un obiect C, dar
nu cu amândouă simultan

40
Notații - 3

Nume Notație Descriere

Agregare Relație de tip parte/întreg (A este

partajată parte din B)

Agregare Relație puternică de tip

compusă parte/întreg (A este parte din B)
Relație de moștenire (A
Generalizare
moștenește de la B)

41
Diagrama de Modelarea
obiecte statică
Diagrama de obiecte

1. Constă din obiecte şi legăturile dintre acestea.

2. Are rolul de a valida diagrama de clase.
3. O legătură reprezintă o relaţie între două obiecte.
Diagrama de obiecte Diagrama de clase
Modelează fapte despre anumite entităţi. Modelează reguli pentru tipuri de entităţi.

Reprezintă obiecte reale. Reprezintă abstractizări ale conceptelor.

Leagă între ele obiecte. Asociază entităţi.

▪ Un obiect este denumit folosind numele acestuia, semnul “:” urmat de

numele clasei căreia îi aparţine: nume obiect : nume clasa .
▪ Pot exista şi obiecte anonime, denumite doar prin numele clasei.
Notaţiile diagramei de clase şi obiecte - comparaţie
Diagrama de clase
Clasa are trei compartimente: nume,
atribute şi operaţii.
Numele clasei este specificat singur în
primul compartiment.
Al doilea compartiment descrie proprietăţi
sub forma atributelor.
Operaţiile apar în descrierea clasei.
Clasele sunt conectate prin asocieri, având
un nume, multiplicitate, constrângeri şi
roluri. Clasele sunt o abstractizare a
obiectelor, deci este necesar să specificăm
câte clase participă într-o asociere.
Diagrama de obiecte
Obiectul are numai două compatrimente:
nume şi atribute.
Formatul numelui unui obiect include şi
numele clasei, toată expresia fiind
subliniată.
Aceste notaţii vor fi întâlnite şi în alte
diagrame care reprezintă obiecte.
Al doilea compartiment defineşte valori
pentru fiecare atribut, pentru testarea
modelului.
Operaţiile nu sunt incluse în obiecte,
deoarece ele sunt identice pentru fiecare
obiect al clasei.
Obiectele sunt conectate printr-o legătură,
care poate avea un nume, roluri, dar nu şi
multiplicităţi. Obiectele reprezintă entităţi
singulare, toate legăturile sunt unu-la-unu,
iar multiplicităţile sunt irelevante.
Diagrama de obiecte în Visual Paradigm

1. Se defineşte diagrama de clase în care clasele au specificate atribute.

2. Se defineşte un obiect în diagrama de obiecte (Instance Specification).

3. Se selectează clasa căreia îi aparţine obiectul: Click dreapta pe obiect
-> Select Classifier-> se bifează şi selectează clasa corespunzătoare
4. Opţional, se dă un nume obiectului.
5. Se definesc valorile pentru atribute: Click dreapta pe obiect -> Slots,
Define Slots (pentru atributele cărora vrem să le dăm valori) ->Edit
Values-> Add -> Text (se introduce valoarea dorită).
6. Se creează legături (Link) între obiecte.
Diagrama de obiecte în Visual Paradigm - exemplu
Recapitulare

1. Ce este şi cum se reprezintă multiplicitatea la nivelul asocierilor dintre

clase? Dar la nivelul atributelor?
2. Denumiţi domeniile de vizibilitate în UML.
3. Care este rolul moştenirii şi cum se identifică?
4. Clasele abstracte pot fi instanţiate?
5. De ce sunt importante numele de rol?
6. Care este diferenţa dintre agregare şi compunere?
7. Ce tip are navigarea implicită la asocierea dintre clase?
8. Cum se reprezintă grafic relația de generalizare?
9. Care este rolul diagramei de obiecte?
10. Câte compartimente are reprezentarea grafică a unui obiect?
11. Cum modelați relațiile dintre clasele următoare: Casa, Bucatarie,
Baie, Dormitor, CutiePostala și Camera?
Cursul 5...

• Diagrama de activitate
• Mecanisme de extensie

48
 ACADEMIA DE STUDII ECONOMICE BUCUREŞTI
FACULTATEA DE CIBERNETICĂ, STATISTICĂ ŞI INFORMATICĂ ECONOMICĂ

P RO I E C TA R E A S I S T E M E LO R
I N F O R M AT I C E

-CURS 5-

BUCUREȘTI
2020-2021
Diagrama de Modelarea
activitate funcțională
Cuprins

▪ Introducere
▪ Activități
▪ Acțiuni
▪ Fluxuri
▪ Flux de control
▪ Flux de obiecte
▪ Nod inițial, nod final al activității, nod final al fluxului
▪ Căi alternative
▪ Căi concurente
▪ Noduri obiect
▪ Acțiuni bazate pe evenimente și acțiuni care apelează comportament
▪ Partiții
▪ Tratarea excepțiilor
Introducere

▪ Scopul diagramei de activitate: modelarea aspectelor care țin de

procesarea procedurală.
▪ Ajută la reprezentarea vizuală a secvenţelor de acţiuni prin care
se doreşte obţinerea unui rezultat.
▪ Se poate realiza pentru unul sau mai multe cazuri de utilizare
sau pentru descrierea unor operaţii complexe.
▪ Nu se construieşte pentru fiecare caz de utilizare şi scenariu,
deoarece nu este necesar, ci numai pentru cele importante.
▪ Descrie fluxul de lucru dintr-un punct de plecare până într-un
punct de terminare, detaliind căile de decizie care pot apărea
într-o activitate.
Introducere

▪ Este importantă în modelarea proceselor de afaceri.

▪ Poate fi folosită pentru a descrie procesare paralelă.
▪ Este bazată pe:
▪ limbajele pentru definirea proceselor de afaceri
▪ concepte consacrate care descriu procesarea concurentă
(rețele Petri)
▪ Conceptele și notațiile acoperă o gamă largă de aplicații
▪ nu se reduc doar la modelarea orientată-obiect
▪ Permite definirea activităților independent de obiecte
▪ se pot modela biblioteci de funcții, procese de afaceri...
 Activitate A
Activitate

▪ Specifică comportamentul definit de utilizator la diferite niveluri de

granularitate
▪ Exemple:
▪ Definirea comportamentului unei operații sub formă de instrucțiuni atomice
▪ Modelarea cursului de acțiuni dintr-un caz de utilizare
▪ Modelarea proceselor de afaceri
▪ O activitate este un graf direcționat Parametru
▪ Nodurile: acțiuni și activități de ieșire
▪ Arce: pentru fluxul de control și de obiect Nume activitate
▪ Fluxul de control și de obiect definește <<preconditie>>
execuția <<postconditie>>
Parametru de
▪ Opțional: intrare
▪ Parametri
▪ Pre- și post-condiții

Nod Arc
 Acțiune A
Acțiune

▪ Elemente de bază cu ajutorul cărora se poate specifica

comportamentul
▪ Sunt atomice, deci nu mai pot fi descompuse
▪ Nu se specifica reguli pentru descrierea unei acțiuni
→Se pot defini în limbaj natural sau în orice limbaj de programare
▪ Procesează valorile de intrare pentru a produce valori de ieșire
▪ Există notații speciale pentru diferite tipuri de acțiuni, cum ar fi:
▪ Acțiuni bazate pe evenimente
▪ Acțiuni care apelează comportament
Arce

▪ Conectează între ele activitățile și acțiunile

▪ Exprimă ordinea de execuție
▪ Tipuri
▪ Arc flux de control
▪ Definește ordinea nodurilor Flux de
▪ Arc flux de obiect control
▪ Folosit pentru a transmite date sau obiecte
▪ Exprimă o dependență bazată pe date/cauzală
între noduri
▪ Condiție (Guard)
▪ Fluxul de control și de obiecte va continua Flux de obiect
doar dacă acea condiție specificată între
paranteze este adevărată
Jeton (Token)

▪ Mecanism virtual de coordonare care descrie cu exactitate execuția

▪ Nu este inclus în notațiile diagramei
▪ Mecanism care acordă acțiunilor permisiunea de execuție

▪ Dacă o acțiune primește un jeton, atunci acțiunea poate fi executată

▪ Când o acțiune este finalizată, aceasta transmite jetonul următoarei
acțiuni, declanșând execuția acesteia
▪ Condițiile pot preveni transmiterea jetonului
▪ Jetonul este stocat în nodul anterior Actiune 1

▪ Jeton control și jeton obiect

▪ Jeton control: “permisiunea de execuție” pentru un nod
Actiune 2
▪ Jeton obiect: transport date + “permisiunea de execuție”
Începerea și terminarea activităților

▪ Nod inițial
▪ Începe execuția unei activități
▪ Transmite jetoane tuturor fluxurilor de ieșire
▪ Păstrează jetoane până când nodurile succesive le acceptă
▪ Pot exista noduri inițiale multiple pentru modelarea concurenței
▪ Nod final al activității
▪ Încheie toate fluxurile unei activități
▪ Primul jeton care ajunge la nodul final al activității încheie întreaga activitate
▪ Inclusiv sub-fluxuri concurente
▪ Sunt șterse alte jetoane de control sau obiect
▪ Nod final al fluxului
▪ Încheie execuția unei ramuri a activității
▪ Toate celelalte jetoane ale activității rămân neafectate
Căi alternative – Nod decizional (Decision)

▪ Folosit pentru a defini ramuri alternative

Actiune 1
▪ Reprezintă un punct de decizie pentru un jeton
▪ Arcele de ieșire au condiții
▪ Sintaxa: [Expresie booleană] Actiune 2 Actiune 3
▪ Jetonul alege o singură cale
▪ Condițiile trebuie să fie mutual exclusive
▪ Comportament decizional
▪ Specifică ce comportament este necesar pentru evaluarea condițiilor
Căi alternative – Nod de îmbinare (Merge)

▪ Realizează convergența fluxurilor mutual exclusive

▪ Transmite jetonul următorului nod

▪ Există și versiunea combinată a nodului decizional și de îmbinare

▪ Nodurile decizionale și de îmbinare pot fi folosite pentru a modela

bucle:
Căi concurente – Nod de bifurcație (Fork)

▪ Nod în care intră un singur flux și ies mai multe

▪ Denotă începutul unor acțiuni paralele
▪ Se realizează copii ale jetonului pentru toate arcele de ieșire
Căi concurente – Nod de sincronizare (Join)

▪ Folosit pentru a sincroniza căi concurenre

▪ Procesarea jetonului
▪ Așteaptă până când jetoanele sunt prezente în toate arcele de intrare
▪ Sincronizează toate jetoanele de control într-unul singur și îl transmite mai
departe
▪ Transmite toate jetoanele obiect

▪ Se poate realiza combinarea nodurilor de bifurcație și sincronizare

Fluxuri de control echivalente

… este echivalent cu…

Exemplu: Crearea și trimiterea invitațiilor pentru un eveniment

▪ În timp ce invitațiile sunt printate, cele deja printate sunt puse în plicuri.
▪ Când toate invitațiile sunt puse în plicuri, acestea sunt trimise
destinatarilor.
Exemplu: Curs universitar

NU sunt echivalente… de ce?

 Obiect
Nod de tip obiect

▪ Conține jetoane obiect

▪ Semnifică schimbul de date/obiecte
▪ Este sursa și destinația unui flux de obiect
▪ Poate include ca informație adițională: tipul, starea obiectului

▪ Variante de notație: nod de tip obiect ca parametru

▪ Pentru activități
Parametru Parametru
de intrare de ieșire

▪ Pentru acțiuni (“pins”)

Exemple: Nod de tip obiect
Sarcina unui arc (weight)

▪ Numărul minim de jetoane care trebuie să fie prezente pentru ca

acțiunea să se execute
▪ Implicit: 1
▪ Toate jetoanele de la sursă sunt oferite simultan
▪ Se folosește cuvântul cheie “weight”
Conector

▪ Folosit atunci când două activități consecutive sunt poziționate în zone

diferite ale diagramei

▪ Fără conector

Se Sustine
inregistreaza examen

▪ Cu conector

Se Sustine
inregistreaza examen
Acțiuni bazate pe evenimente

▪ Care trimit semnale

▪ Acțiune care trimite semnal

▪ Care acceptă evenimente

▪ Acțiune care acceptă eveniment

▪ Acțiune care acceptă eveniment de tip timp

Exemplu: Acțiune care acceptă evenimente
Acțiune care apelează comportament

▪ Execuția unei acțiuni poate apela o activitate

▪ Conținutul activității apelate este modelat în altă parte
▪ Avantaje:
▪ Modelele devin mai clare
▪ Reutilizarea Numele activității apelate

Simbol specific
Partiții

▪ Sunt similare culoarelor dintr-un bazin de înot (“Swimlane”)

▪ Permit gruparea nodurilor și arcelor unei activități în funcție de
responsabilități
▪ Responsabilitățile reflectă unitățile organizaționale sau rolurile
▪ Realizează o mai bună structurare a diagramei
▪ Nu schimbă semantica execuției
▪ Pot fi imbricate în funcție de necesități
▪ Exemple: partițiile Student și Angajat Institut (cu subpartițiile
Profesor și Secretar)
Tratarea excepțiilor (Exception Handler)

▪ Se referă la excepții predefinite

▪ Definește modul în care sistemul trebuie să reacționeze într-o anumită
situație de eroare
▪ Handler-ul de excepții înlocuiește acțiunea în locul unde a apărut
eroarea
▪ Dacă are loc eroarea e, atunci:
▪ Toate jetoanele din Acțiunea A sunt șterse
▪ Se activează handler-ul de excepții
e ▪ Se execută handler-ul de excepții în loc
de Acțiunea A
▪ Execuțiile următoare se realizează în mod
normal
▪ Obs: în Visual Paradigm se creează un pin de
intrare cu un parametru de tip Exception
Example: Exception Handler
Tratarea excepțiilor – Regiune dintr-o activitate care poate fi
întreruptă

▪ Definește un grup de acțiuni a căror execuție trebuie terminată imediat

dacă are loc un anumit eveniment. În acest caz, se execută un alt
comportament

▪ Dacă E are loc în timp ce B sau C sunt executate, atunci:

▪ Se activează mecanismul de tratare a excepțiilor
▪ Toate jetoanele de control din interiorul dreptunghiului sunt șterse
▪ D este activată și executată

▪ Se întrerupe fluxul normal de execuție

Exemplu: Regiune dintr-o activitate care poate fi întreruptă
Notații -1

Nume Notație Descriere

Reprezintă o acțiune (este
Nod acțiune atomică)

Nod activitate Reprezintă o activitate (mai poate

fi descompusă)

Nod inițial Începutul execuției unei activități

Nod final al Sfârșitul tuturor fluxurilor de

activității execuție ale unei activități
Notații -2

Nume Notație Descriere

Folosită pentru divergența
Nod decizional fluxurilor mutual exclusive

Folosită pentru convergența

Nod de îmbinare fluxurilor mutual exclusive

Nod de bifurcație Folosită pentru divergența

fluxurilor concurente

Nod de Folosită pentru convergența

sincronizare fluxurilor concurente
Notații -3

Nume Notație Descriere

Nod final al
Sfârșitul execuției unui flux al activității
fluxului

Arc Conectează nodurile unei activități

Acțiune care
Acțiune A apelează o activitate cu
apelează
același nume
comportament

Grupează nodurile și arcele din

Partiție
cadrul unei activități
Notații -4

Nume Notație Descriere

Acțiune trimite Transmite un semnal către un
semnal receptor

Acțiune care
Așteaptă un eveniment E sau un
acceptă
eveniment de tip T
evenimente

Nod de tip Obiect Conțin date sau obiecte

obiect

Parametri
pentru activități
Conțin date și obiecte ca parametri
Parametri de intrare sau ieșire
pentru acțiuni
(pins)
Notații -5

Nume Notație Descriere

Handler-ul de excepții se execută

Handler de
în loc de acțiune în cazul apariției
excepții
evenimentului e

Regiune care Fluxul continuă pe o cale diferită

poate fi atunci când este detectat
întreruptă evenimentul E
Mecanisme de Extinderea
limbajului
extensie UML
Cuprins

▪ Introducere

▪ Note

▪ Stereotipuri

▪ Constrângeri

▪ Valori etichetate
Introducere

▪ UML are o largă aplicabilitate în proiecte de diferite tipuri și

dimensiuni.

▪ În plus față de diagramele din standard, UML a fost creat având

capacitatea de a se extinde.

▪ Această extensibilitate a limbajului îl face versatil.

Introducere

▪ Mecanismele de extensie UML includ:

▪ Note - pot fi folosite pentru a adăuga informații suplimentare în
diagramele UML, oferind explicații care nu pot fi surprinse direct
de către notațiile din diagrame.
▪ Stereotipuri - sunt un mecanism folosit pentru a clasifica orice
element de modelare în UML și facilitează înțelegerea
numeroaselor diagrame și modele.
▪ Constrângeri - sunt restricții aplicate modelelor care ajută la
îmbunătățirea calității modelului.
▪ Valori etichetate - sunt identificatori aplicați modelelor, având rolul
de a le eticheta cu proprietăți predefinite.
Note

▪ Sunt un bun mijloc descriptiv de clarificare a diagramelor UML.

▪ Oferă explicații suplimentare despre dependențele dintre elementele
unei diagrame UML.
▪ Mecanismul este foarte util, în special în diagramele statice structurale,
unde este dificil să se arate dependențe.
▪ Sunt reprezentate de un dreptunghi cu un colț îndoit și sunt legate de
orice alte elemente din diagramă.
▪ Notele dintr-o diagramă UML sunt similare comentariilor dintr-un cod
sursă bine documentat. Ajută la înțelegerea semnificațiilor mai profunde
și implicite din spatele diagramei.
▪ Pot conține: comentarii textuale, simboluri grafice, descrieri detaliate,
linkuri către pagini web și referințe la alte documente.
▪ Nu au niciun efect asupra semanticii unui model (nu modifică sensul
modelului).
Note
Stereotipuri - exemple << >>

▪ Stereotipuri comune care pot apărea în diagramele de clase:

▪ Clasă Entity – modelează obiecte din domeniul afacerii
▪ Clasă Boundary – modelează interfețe
▪ Clase Control - modelează logica aplicației
Stereotipuri << >>

▪ Stereotipurile sunt folosite pentru a clasifica aproape orice element din

UML.
▪ Deși sunt, în mare parte, opționale, ele ajută la înțelegerea
diagramelor, oferind o modalitate de grupare la nivel înalt a elementelor
din diagramă.
▪ Prin intermediul stereotipurilor, se pot folosi elementele de bază, dar cu
proprietăți speciale, ca semantică și notație.
▪ Strict din punct de vedere semantic, este echivalent cu realizarea unor
noi elemente de modelare.
▪ O astfel de grupare ajută și la o mai bună comunicare a scopului
elementului UML.
▪ Utilizatorii pot crea propriile stereotipuri.
Stereotipuri obligatorii << >>

▪ Există și stereotipuri obligatorii, predefinite în cadrul limbajului.

▪ În alte cazuri, stereotipurile pentru relații sunt implicite prin simbolul sau
pictograma folosită pentru a reprezenta relația respectivă.
▪ Stereotipurile pentru relațiile la nivelul claselor sunt reprezentate doar
prin pictograme.
▪ De exemplu, stereotipul „moștenire” într-o relație clasă-clasă nu trebuie
etichetat. Vârful săgeții care reprezintă relația de moștenire între două
clase face ca relația să fie unică și clară chiar și fără eticheta de
stereotip.

Dați exemple de astfel de stereotipuri

pentru relațiile dintre cazuri de utilizare
și relațiile dintre clase!
Stereotipuri pentru clase << >>

▪ Clasa Entity (Entitate) <<entity>>

▪ Reprezintă stereotipul care descrie o entitate din domeniul analizat, de
exemplu, un client sau o factură.
▪ Clasele entități alcătuiesc principalul set de clase al unui sistem și, prin
urmare, sunt primele clase care trebuie descoperite în timpul etapei de
analiză.
▪ De obicei, o diagramă de clasă la nivel de analiză este aproape
întotdeauna formată doar din clase entitate. În etapa de proiectare se pot
adăuga și alte categorii de clase stereotip.
▪ Clasa Boundary (Interfață) <<boundary>>
▪ Indică faptul că acea clasă este o interfață, adică o graniță între sistem și
utilizator.
▪ Clasele interfață pot descrie diferite elemente precum formulare sau
pagini web sau interfețe la sisteme și dispozitive externe (de exemplu, o
interfață electronică pentru schimb de date între două bănci).
Stereotipuri pentru clase << >>

▪ Clasa Control <<control>>

▪ Este un stereotip al unei clase care este folosit pentru a lega clasele
entități la clasele interfață, în scopul reducerii cuplării clasei.
▪ Clasele control sunt clase temporare și gestionează un set de interacțiuni,
secvențele și ordinea temporală într-un sistem și apoi dispar.
▪ Ajută la decuplarea claselor entitate de clasele interfață.
▪ Clasa Utility (Utilitară) <<utility>>
▪ Sunt clase oferite de mediul de dezvoltare. Sunt, de obicei clase care
oferă funcții utilitare generice și aplicabile în multe situații.
▪ De exemplu, clasele care oferă funcții pentru lucrul cu date de tip
dată/timp sau conversii ale monedelor.
▪ Clasele abstracte
▪ Sunt o categorie importantă de clase în orientarea obiect, chiar dacă nu
au asociat un stereotip.
▪ Numele lor apare scris cu italic.
Constrângeri - exemple { }
Constrângeri { }

▪ O constrângere este o regulă suplimentară asociată unei diagrame

UML pentru a da o semnificație specială unui element din diagramă,
relației dintre mai multe elemente sau întregii diagrame.

▪ Este o extensie a semanticii unui element UML, permițând adăugarea

de reguli noi sau modificarea celor existente.

▪ O constrângere specifică condițiile care trebuie respectate pentru ca

modelul să fie corect construit.

▪ Poate fi utilizată pentru a extinde notația de bază a unui element din

model sau pentru a vizualiza părți din specificațiile unui element care
nu au reprezentări grafice.
Valori etichetate { e = “v” }

▪ Valorile etichetate extind proprietățile unui element de modelare,

permițând crearea de informații noi în specificațiile acelui element.

▪ Sunt descrise prin intermediul perechilor de cuvinte cheie-valoare ale

elementelor din model, în care cuvintele cheie sunt atribute.

▪ Pot fi definite pentru elementele de model existente sau pentru

stereotipurile individuale, astfel încât întregul stereotip să aibă asociată
acea valoare etichetată.

▪ O valoare etichetată nu este egală cu un atribut al clasei.

▪ Poate fi asimilată metadatelor, deoarece se aplică elementului în sine și

nu instanțelor sale.

▪ Grafic, este redată ca un șir inclus între acolade, care este plasat sub
numele unui alt element de model. Șirul constă dintr-un nume
(eticheta), un separator (simbolul =) și o valoare (a etichetei).
Valori etichetate { e = “v” }

▪ Utilizări frecvente:
▪ specificarea proprietăților relevante pentru generarea codului sursă

▪ gestiunea configurațiilor

▪ Exemple: se poate specifica limbajul de programare în care va fi

implementată o anumită clasă sau poate fi folosit pentru a indica
autorul și versiunea unei componente.
Exerciții -1

Identificați posibilele căi de execuție pentru diagrama de mai jos.

Exerciții -2

Identificați posibilele căi de execuție pentru diagrama de mai jos.

Exerciții -3

Identificați posibilele căi de execuție pentru diagrama de mai jos.

Exerciții -4

Identificați care dintre elemente de mai jos apar în această diagramă:

- Evenimente inițiale multiple
- Evenimente finale multiple
- Acțiuni concurente
- Acțiuni mutual exclusive
Exerciții -5

Analizați componentele activității A.

- Ce acțiuni trebuie finalizate pentru a se putea executa acțiunea A7?
- Ce se întâmplă dacă activitatea A7 este finalizată, iar A3 este încă în
execuție?
 ACADEMIA DE STUDII ECONOMICE BUCUREŞTI
FACULTATEA DE CIBERNETICĂ, STATISTICĂ ŞI INFORMATICĂ ECONOMICĂ

P RO I E C TA R E A S I S T E M E LO R
I N F O R M AT I C E

-CURS 6-

BUCUREȘTI
2020-2021
Diagramele de Modelarea
mașini cu stări dinamică
Cuprins

▪ Introducere
▪ Stări
▪ Tranziţii
▪ Tipuri de evenimente
▪ Tipuri de stări
▪ Puncte de intrare și ieșire

3
Introducere

▪ Fiecare obiect trece printr-un număr finit de stări diferite pe parcursul

vieții sale
▪ Diagrama de mașini cu stări este utilizată:
▪ Pentru modelarea stărilor posibile ale unui sistem sau obiect
▪ Pentru a arăta cum au loc tranzițiile dintre stări ca urmare a unor
evenimente
▪ Pentru a arăta ce comportament prezintă sistemul sau obiectul în fiecare
stare
▪ Exemplu: descrierea la nivel înalt a comportamentului unei săli de
cursuri Tranziție Stare

4
Exemplu: SalaCurs cu detalii

class SalaCurs {
private boolean libera;

public void ocupa() {

libera=false;
}
public void elibereaza() {
libera=true;
}
}

5
Stare

▪ Stări = noduri ale mașinii de stare

▪ Când o stare este activă
▪ Obiectul se află în starea respectivă
▪ Toate activitățile interne specificate în această stare pot fi executate
▪ O activitate poate consta din mai multe acțiuni
▪ entry / Activity(...)
▪ Executată când obiectul intră în stare
▪ exit / Activity(...)
▪ Executată când obiectul iese din stare
▪ do / Activity(...)
▪ Executată cît timp obiectul rămâne în această
stare

6
Tranzitie

▪ Schimbare de la o stare la alta

Eveniment Condiție Secvență de acțiuni(efect)

Stare sursă Tranziție Stare țintă

7
Tranziție – Sintaxă

▪ Eveniment (trigger)
▪ Stimul exogen
▪ Poate declanșa o tranziție a unei stări
▪ Condiție (guard)
▪ Expresie booleană
▪ Dacă evenimentul are loc, condiția este verificată
▪ Arunci când condiția este adevărată
▪ Toate activitățile din starea actuală sunt încheiate
▪ Orice activitate de ieșire relevantă este executată
▪ Tranziția are loc
▪ Arunci când condiția este falsă
▪ Nu are loc nici o tranziție, evenimentul este anulat
▪ Activitate (efect)
8
▪ Secvența acțiunilor executate în timpul unei tranziții de stare
Tranziție – Tipuri (1/2)
Tranziție internă
▪ Dacă are loc eveniment1
▪ Obiectul rămâne în stare1
▪ Activitatea3 este executată
Tranziție externă
▪ Dacă are loc eveniment1
▪ Obiectul iese din starea1 și
Activitatea2 este executată
▪ Activitatea3 este executată
▪ Obiectul intră în starea1 și
Activitatea1 este executată
9
Tranziție – Tipuri (2/2)

▪ Când au loc următoarele tranziții?

Dacă are loc e1, A1 este anulată și obiectul își
schimbă starea în S2
Dacă are loc e1 și g1 este evaluată ca fiind
adevărată, A1 este anulată și obiectul își
schimbă starea în S2
Imediat ce execuția lui A1 este terminată, se
generează un eveniment de finalizare care
inițiază tranziția la S2
Imediat ce execuția lui A1 este terminată, se
generează un eveniment de finalizare; dacă g1
este evaluată ca fiind adevărată, tranziția are
loc; dacă nu, această tranziție nu se poate
întâmpla niciodată
10
Tranziție - Secvență de executare a activității

▪ Presupunând că S1 este starea activă, care este valoarea lui x după

ce se realizează e?

S1 devine activă, x este setat la valoarea 4

e are loc, condiția este verificată și evaluată ca adevărată
S1 este părăsită, x este setat la 5
tranziția are loc, x este setat la 10
se intră în S2, x este setat la 11

11
Eveniment - Tipuri (1/2)

▪ Eveniment de tip Semnal

Primirea unui semnal
▪ Ex: click_dreapta, trimiteSMS(mesaj)
▪ Eveniment de tip Apel
Apelul unei operații
▪ Ex: ocupa(utilizator,sala_de_prelegeri),
înregistrează(examen)
▪ Eveniment de timp
Tranziție bazată pe timp
▪ Relativă: în funcție de momentul producerii evenimentului
▪ Ex: după(5 secunde)
▪ Absolută
▪ Ex: când(oră==16:00), când(data==2020.01.01)

12
Eveniment - Tipuri (2/2)
▪ Orice eveniment de primire
Se folosește pentru a modela tranzițiile de tip else
▪ Cuvânt cheie all
▪ Din stare S1 obiectul trece în starea S2 la producerea
evenimentului e1 și în S4 la producerea oricărui
eveniment
▪ Eveniment de finalizare
Generat automat atunci când tot ceea ce trebuie făcut
în starea curentă este finalizat
▪ Eveniment de schimbare
Se verifică permanent îndeplinirea unei condiții
▪ Ex: când(x > y), după(90min)

13
Eveniment de schimbare vs. Condiție

Verificat permanent

Verificată numai când are loc evenimentul

14
Stare inițială

▪ Desemnează “începutul” unei diagrame de stare

▪ Este o pseudostare
▪ Tranzitorie, sistemul nu poate rămâne în acea stare
▪ Mai degrabă o structură de control decât o stare reală
▪ Nu are fluxuri de intrare
▪ Dacă există mai multe fluxuri de ieșire
▪ Condițiile trebuie să fie mutual exclusive și să acopere toate situațiile
posibile pentru a se asigura că este atinsă exact o stare țintă
▪ Dacă starea inițială devine activă, obiectul trece imediat în starea
următoare
▪ Nu se pot asocia activități pseudostărilor

15
Stare finală și nod de încheiere

Stare finală
▪ Este o stare reală
▪ Marchează încheierea secvenței de stări
▪ Obiectul poate rămâne într-o stare finală pentru totdeauna

Nodul de încheiere
▪ Este o pseudostare
▪ Încheie mașina de stări
▪ Obiectul modelat își încetează existența, adică este șters

16
Nod decizional

▪ Este o pseudostare
▪ Folosit pentru modelarea tranzițiilor alternative

echivalent?

echivalent?

≠
17
Exemplu: Nod decizional

18
Noduri de paralelizare și sincronizare

Nodul de paralelizare
▪ Este o pseudostare
▪ Împarte fluxul de control în mai multe fluxuri concurente
▪ Are un singur flux de intrare
▪ Are mai multe fluxuri de ieșire
▪ Pe fluxurile de ieșire nu se specifică evenimente sau condiții

Nodul de sincronizare
▪ Este o pseudostare
▪ Fuzionează fluxuri concurente multiple
▪ Are mai multe fluxuri de intrare
▪ Are un singur flux de ieșire
▪ Pe fluxurile de ieșire nu se specifică evenimente sau condiții

19
Stare compusă

▪ Sinonime: stare complexă, stare imbricată

▪ Conține alte stări - „substari”
▪ Doar una dintre substările sale este activă la un moment de timp

Stare compusă

Substări

20
Intrarea într-o stare compusă (1/2)

▪ Tranziție către graniță Eveniment Stare Activități

▪ Nodul inițial al stării compuse executate
este activat „Început“ S3

e2 S1/S1.1 a0-a2-a3-a4

21
Intrarea într-o stare compusă(2/2)

▪ Tranziția către o substare Eveniment Stare Activități

▪ Substarea este activată executate
„Început“ S3

e1 S1/S1.2 a0-a1-a3-a7

22
23
Ieșirea dintr-o stare compusă (1/3)

▪ Tranziție dintr-o substare Eveniment Stare Activități

executate
„Început“ S1/S1.1 a3-a4

e3 S2 a6-a5-a2-a1

23
Ieșirea dintr-o stare compusă(2/3)

▪ Tranziția din starea compusă Eveniment Stare Activități

executate
Indiferent ce substare a lui S1
„Început“ S1/S1.1 a3-a4
este activă, îndată ce are loc
e5, sistemul trece la S2 e5 S2 a6-a5-a3-a1

24
Ieșirea dintr-o stare compusă (3/3)

▪ Trecerea finalizată de la starea Eveniment Stare Activități

compusă executate
„Început“ S1/S1.1 a3-a4

e4 S1/S1.2 a6-a7

e4 S2 a8-a5-a1

25
Starea submașină

▪ Permite reutilizarea părților diagramelor mașinilor de stare în alte

diagrame ale mașinilor de stare
▪ Notatie: stare:stareSubmasina
▪ De îndata ce starea submașinii este activată, este executat
comportamentul acesteia
▪ Corespunde apelului unei subrutine în limbaje de programare

Simbol specific
(opțional)

26
Puncte de intrare și ieșire

▪ Mecanism de încapsulare
▪ Se va intra sau se va ieși dintr-o stare compusă printr-o altă stare decât
stările inițiale și finale
▪ Tranziția externă nu trebuie să cunoască structura stării compuse
▪ Punctele de intrare și ieșire reprezintă un tip de mecanism de încapsulare

Vedere externa
External view

27
Exemplu: Puncte de intrare și ieșire

28
Elemente de notație (1/2)
Nume Notație Descriere
Descrierea unui „interval de timp”
specific în care un obiect se regăsește
Stare pe parcursul „ciclului său de viață”. În
cadrul unei stări, diferite activități pot fi
executate de obiect.
Tranziția de la o stare sursa S la o
Tranziție
stare țintă T
Începutul unei diagrame de mașini de
Stare inițială
stări
Încheierea unei diagrame de mașini de
Stare finală
stări

Nod de Încheierea diagramei de mașini de

încheiere stări a unui obiect

29
Elemente de notație (2/2)
Nume Notație Descriere

Nod din care pot origina tranziții

Nod decizional
alternative multiple

Divizarea unei tranziții în mai multe

Nod de paralelizare
tranziții paralele

Îmbinarea mai multor tranziții paralele

Nod de sincronizare
într-o singură tranziție

30
Diagramele de Modelarea
interacțiune dinamică
Introducere

▪ Modelarea comportamentului care implică mai multe obiecte

= presupune interacțiunea între obiecte
▪ Interacțiunea
▪ Specifică modul cum mesajele și datele sunt schimbate între partenerii
care interacționează
▪ Partenerii interacțiunii
▪ Uman (profesor, administrator, …)
▪ Non-uman (server, imprimantă, software executabil, …)
▪ Example de interacțiuni
▪ Conversații între persoane
▪ Schimbul de mesaje între oameni și sisteme software
▪ Protocoale de comunicare
▪ Secvențe de metode într-un program
▪ …

32
Diagramele de interacțiune

▪ Folosite pentru a specifica interacțiuni

▪ Modelează scenarii concrete
▪ Descriu secvențe de comunicare la diferite nivele de detaliu

▪ Diagramele de interacțiune pot descrie:

▪ Interacțiunea unui sistem cu mediul său
▪ Interacțiunea dintre părți ale sistemului în scopul de a arăta cum poate fi
implementat un caz de utilizare
▪ Comunicarea dintre procese în care partenerii implicați trebuie să
respecte anumite protocoale
▪ Comunicarea la nivelul claselor (apeluri de operații, comportamentul inter-
obiecte)

33
Diagrama de secvență

▪ Este o diagramă bidimensională

▪ Axa orizontală: arată partenerii care interacționează
▪ Axa verticală: ordinea cronologică a interacțiunilor
▪ Interacțiunea = secvență de specificații ale unor evenimente
Axa temporală

Parteneri de interacțiune

34
Parteneri în cadrul interacțiunii

▪ Partenerii care interacționează sunt descriși sub forma unor linii de

viață
▪ Partea superioară a liniei de viață
▪ Dreptunghi care conține expresia NumeRol:Clasă
▪ Numele de rol sunt un concept mai general decât obiectele
▪ Obiectul poate juca diferite roluri de-a lungul liniei sale de viață
▪ Partea inferioară a liniei de viață
▪ Linie verticală, de obicei, punctată
▪ Reprezintă durata de viață a obiectului asociat acesteia
Partea superioară
a liniei de viață

Partea inferioară a
liniei de viață

35
Schimbul de mesaje (1/2)

▪ Interacțiune: secvență de evenimente

▪ Mesajele sunt definite prin intermediul evenimentului de trimitere și a
evenimentului de primire
▪ Specificarea execuției
▪ Reprezentată ca un dreptunghi subțire
▪ Folosită pentru a vizualiza când un partener execută un anumit
comportament

Eveniment de trimitere Eveniment de primire

Specificarea execuției

36
Schimbul de mesaje (2/2)
Ordinea mesajelor:
… pe o linie de viață … pe linii de viață diferite

„se întâmplă înainte de“

… pe linii de viață diferite care schimbă mesaje

37
Mesaje (1/3)

▪ Mesaj sincron
▪ Emițătorul așteaptă până primește un mesaj de răspuns
înainte de a continua
▪ Sintaxa numelui mesajului: mesaj(par1,par2)
▪ mesaj: numele mesajului
▪ par: parametrii separați prin virgulă
▪ Mesaj asincron
▪ Emițătorul continuă fără să aștepte un mesaj de răspuns
▪ Sintaxa numelui mesajului: mesaj(par1,par2)
▪ Mesaj răspuns
▪ Poate fi omis dacă locația sau contextul sunt evidente
▪ Sintaxa: atrib=mesaj(par1,par2):val
▪ atrib: valoarea returnată poate fi atribuită opțional unei variabile
▪ mesaj: numele mesajului
▪ par: parametrii separați prin virgulă
▪ val: valoarea returnată

38
Mesaje (2/3)

▪ Crearea obiectului
▪ Reprezentată prin linie punctată
▪ Vârful săgeții indică înspre linia de viață a
obiectului creat
▪ Se folosește cuvântul cheie new

▪ Distrugerea obiectului
▪ Obiectul este șters
▪ Reprezentată cu (×) la finalul liniei de viață

39
Mesaje (3/3)

▪ Mesaj găsit
▪ Emițătorul unui mesaj este necunoscut sau irelevant
▪ Mesaj pierdut
▪ receptorul unui mesaj este necunoscut sau irelevant
▪ Mesaj consumator de timp
▪ Poate fi numit și “mesaj cu durată”
▪ De obicei, se presupune că mesajele se transmit
fără nicio pierdere de timp
▪ Exprimă faptul că trece un timp între trimiterea și
primirea mesajului

40
Mesaje asincron/sincron

A B

Comunicare prin două mesaje Comunicare printr-un mesaj sincron

asincrone și un mesaj răspuns
Student așteaptă primirea unui
răspuns înainte de a continua

41
Fragmente combinate

▪ Modelează diferite tipuri de structuri de control

▪ Permit să introducem logică procedurală în diagrama de secvență
▪ Există 12 tipuri predefinite de operatori
Fragment combinat

Operator

Operand

Operand
Operand

42
Tipuri de fragmente combinate
Operator Scop
alt Interacțiune alternativă
Alternativ și
iterativ
opt Interacțiune opțională

loop Interacțiune repetată

break Interacțiune excepție

seq Ordonare slabă

Concurență și

strict Ordonare strictă

ordonare

par Interacțiune concurentă

critical Interacțiune atomică

ignore Interacțiune irelevantă

Filtre și aserțiuni

consider Interacțiune relevantă

assert Interacțiune confirmată

neg Interacțiune invalidă

43
Fragmentul alt

▪ Folosit pentru modelarea

secvențelor alternative
▪ Similar structurii switch din
Java
▪ Sunt folosite condiții pentru a
selecta o singură cale de
execuție
▪ Condițiile
▪ Descrise între paranteze
drepte
▪ implicit: true
▪ predefinită: [else]

▪ Pot exista operanzi multipli

▪ Condițiile trebuie să fie mutual
exclusive

44
Fragmentul opt

▪ Modelează secvențe
opționale
▪ Execuția la momentul rulării
este dependentă de condiție
▪ Are doar un singur operand
▪ Similară structurii if fără
ramura else
▪ Echivalent fragmentului alt
cu doi operanzi, dintre care
unul este gol

45
Fragmentul loop

▪ Exprimă o secvență care trebuie executată în mod repetat

▪ Are un singur operand
▪ Desemnat prin cuvântul cheie loop, urmat de numărul minim/maxim de
iterații (min..max) sau (min,max)
▪ implicit: (*) .. fără limită superioară
▪ Condiție
▪ Evaluată imediat ce a fost atins numărul minim de operații
▪ Verifică pentru fiecare iterație dacă se încadrează în limitele (min,max)
▪ Atunci când condiția este evaluată ca falsă, execuția este terminată
Maxim
Minim
Condiție Notații alternative:

Fragmentul loop(3,8) = loop(3..8)

loop este loop(8,8) = loop (8)
executat cel puțin loop = loop (*) = loop(0,*)
o dată și atâta
timp cât a<1 este
46
adevărată
Fragmentul break

▪ Modalitate de tratare a excepțiilor

▪ Exact un singur operand cu o condiție
▪ Atunci când condiția este adevărată:
▪ Se execută interacțiunile din cadrul
acestui operand
▪ Restul operațiilor ale fragmentului din jurul
său vor fi omise
▪ Interacțiunile continuă în următorul fragment
de nivel mai înalt
▪ Comportament diferit față de opt

Nu se execută dacă este executat break

47
Fragmentele loop și break - Exemplu

48
Referința interacțiunii

▪ Integrează o diagramă de secvență în altă diagramă de secvență

49
Constrângeri de timp

▪ Tipuri
▪ Moment de timp pentru
producerea unui eveniment
▪ Relativ: ex. după(5sec)
▪ Absolut: ex. la(12.00)
▪ Perioadă de timp între două
evenimente
▪ {min..max}
▪ Ex. {12.00..13.00}
▪ Acțiuni predefinite
▪ acum: momentul curent
▪ Poate fi alocată unui atribut și
folosită apoi într-o constrângere
de timp
▪ Durata: calculul duratei
transmiterii unui mesaj

50
Constrângeri de timp

▪ Tipuri
▪ Moment de timp pentru
producerea unui eveniment
▪ Relativ: ex. după(5sec)
▪ Absolut: ex. la(12.00)
▪ Perioadă de timp între două
evenimente
▪ {min..max}
▪ Ex. {12.00..13.00}
▪ Acțiuni predefinite
▪ acum: momentul curent
▪ Poate fi alocată unui atribut și
folosită apoi într-o constrângere
de timp
▪ Durata: calculul duratei
transmiterii unui mesaj

51
Invarianța

▪ Arată că o anumită condiție trebuie îndeplinită la un moment de timp

▪ Este întotdeauna alocată unui linii de viață
▪ Este evaluată înainte de apariția unui eveniment ulterior
▪ Dacă invarianța nu este adevărată, atunci fie modelul, fie
implementarea, sunt incorecte
▪ Trei notații alternative

52
Patru tipuri de diagrame de interacțiune (1/4)

▪ Bazate pe aceleași concepte

▪ În general sunt echivalente pentru interacțiuni simple, dar din
perspective diferite

▪ Diagrama de secvență
▪ Axa verticală:
ordinea cronologică
▪ Axa orizontală:
partenerii interacțiunii

53
Patru tipuri de diagrame de interacțiune (2/4)

▪ Diagrama de comunicare
▪ Modelează relațiile dintre partenerii care comunică
▪ Privesc interacțiunile din perspectiva: cine cu cine comunică
▪ Timpul nu este definit ca o dimensiune separată
▪ Ordinea mesajelor este dată de un prefix asociat acestora

54
Patru tipuri de diagrame de interacțiune (3/4)

▪ Diagrama de timp
▪ Arată schimbările stărilor partenerilor care interacționează ca rezultat al
apariției evenimentelor
▪ Axa verticală: partenerii care interacționează
▪ Axa orizontală: ordinea cronologică

55
Patru tipuri de diagrame de interacțiune (4/4)

▪ Diagrama interacțiunilor de ansamblu

▪ Vizualizează ordinea diferitelor interacțiuni
▪ Permite aranjarea diferitelor diagrame de interacțiune într-o ordine logică
▪ Folosesc notațiile de bază din diagrama de activitate

56
Notații (1/2)
Nume Notație Descriere

Partenerii care interacționează și sunt

Linie de viață
implicați în comunicare

Mesaj de Momentul în care un partener implicat

distrugere în interacțiune încetează să existe

Fragment Construcții care modelează structuri de

combinat control

57
Notații (2/2)
Nume Notație Descriere
Inițiatorul așteaptă un mesaj de
Mesaj sincron
răspuns

Mesaj răspuns Răspuns la un mesaj sincron

Comunicare Emițătorul continuă activitatea sa după

asincronă trimiterea mesajului asincron

Mesaj pierdut Mesaj către un receptor necunoscut

Mesaj găsit Mesaj de la un emițător necunoscut

58
Recapitulare
1. Care sunt elementele unei tranziții in diagrama de mașini cu stări?
2. Ce tipuri de activități interne se pot executa în interiorul unei stări?
3. Prin ce se caracterizează activitatea de tip do?
4. Pentru ce este folosit nodul decizional?
5. Dacă o stare are o tranziție de ieșire fără niciun eveniment specificat, prin ce
mecanism se va produce tranziția?
6. Din ce este formată o stare compusă?
7. Ce pot descrie diagramele de interacțiune?
8. Care sunt dimensiunile diagramei de secvență?
9. Cum se reprezintă un partener al interacțiunii în diagrama de secvență?
10.Ce reprezintă un mesaj sincron? Dar un mesaj de distrugere a unui obiect?
11.Care este rolul fragmentelor combinate?
12.Ce structură de control modelează fragmentul alt?
13.Explicați diferența dintre fragmentele opt și break.
14.Prin ce diferă diagrama de comunicare de cea de secvență?
Modelarea proceselor de afaceri – limbajul BPMN

Cuprins
✓ Introducere
✓ Managementul și modelarea proceselor de afaceri
✓ Limbajul BPMN
✓ Elemente ale limbajului BPMN
✓ Obiecte de flux
✓ Obiecte de conectare
✓ Obiecte de partiţionare
✓ Date
✓ Artefacte
✓ Tipuri de diagrame
Introducere - 1

Managementul proceselor de afaceri se bazează pe observația că fiecare produs pe care

o companie îl oferă pe piață este rezultatul mai multor activități desfășurate în cadrul
companiei.

Procesele de afaceri sunt instrumentul cheie pentru organizarea acestor activități și

pentru îmbunătățirea înțelegerii relațiilor dintre acestea.

Tehnologia informației în general și sistemele informatice în special joacă un rol

important în gestiunea proceselor de afaceri, deoarece tot mai multe activități pe care le
desfășoară o companie au suportul unor sisteme informatice.

Activitățile unui proces de afaceri pot fi realizate manual de către angajații companiei sau
cu ajutorul sistemelor informatice. Există, de asemenea, activități ale unui proces de
afaceri care pot fi realizare automat de sistem, fără nicio implicare umană.

3
Introducere - 2
În multe companii există un decalaj între aspectele organizaționale ale afacerii și
tehnologia informațională care este implementată.

Reducerea acestui decalaj între organizație și tehnologie este importantă, deoarece

companiile sunt constrânse să ofere clienților lor produse mai bune și specifice.

La nivel organizațional, procesele de afaceri sunt esențiale pentru înțelegerea modului

în care funcționează companiile.Au un rol important în proiectarea și realizarea
sistemelor informatice flexibile.

Aceste sisteme informatice oferă baza tehnică pentru crearea rapidă de noi
funcționalități care realizează produse noi și pentru adaptarea funcționalității existente
în scopul satisfacerii noilor cerințe ale pieței.

Managementul proceselor de afaceri este influențat de concepte și tehnologii din

diferite domenii ale administrării afacerilor și informatică.
4
Procese de afaceri
Un proces de afaceri (engl. business process) constă dintr-un
set de activități care sunt efectuate în mod coordonat într-un
mediu organizațional și tehnic.

Aceste activități realizează în comun un obiectiv de afaceri.

Fiecare proces de afaceri este adoptat de o singură

organizație, dar poate interacționa cu procesele de afaceri
efectuate de către alte organizații.

Tehnologia informației influențează gestiunea proceselor de

afaceri, tot mai multe activități desfășurate în cadrul unei
organizații necesită automatizare, beneficiind astfel de
suportul unor sisteme informatice.
5
Managementul proceselor de afaceri
Managementul proceselor de afaceri (engl. business process
management) include concepte, metode, și tehnici necesare
pentru a sprijini proiectarea, administrarea, configurarea,
implementarea și analiza proceselor de afaceri.

Baza managementului proceselor de afaceri este

reprezentarea explicită a procesele de afaceri cu activitățile
lor și constrângerile de execuție dintre acestea.

Odată definite procesele de afaceri, acestea pot fi supuse

analizei, îmbunătățite și implementate.

Un sistem de gestiune a proceselor de afaceri (engl.

business process management system) este un sistem
software generic care folosește reprezentări explicite ale
proceselor de afaceri pentru a coordona implementarea
acestora.
6
Modelarea proceselor de afaceri

Există diferite niveluri ale modelării proceselor:

Hărţi de procese – simple fluxuri de lucru ale activităţilor

Descrieri ale proceselor – fluxuri de lucru extinse cu informaţii

adiţionale, dar nu suficiente pentru a defini procesul în detaliu

Modele de procese – fluxuri de activităţi extinse cu informaţii

suficiente pentru a putea analiza, simula şi/sau executa procesul

BPMN suportă toate aceste niveluri

BPMN = Business Process Model and Notation

7
Limbajul BPMN - caracteristici

Standard creat și întreținut
de OMG
Înainte de standardizare,
fiecare companie sau
producător de instrumente Este independent din
de modelare avea definită punct de vedere tehnologic
propria metodă de
reprezentare

Permite îmbunătățirea
Are un limbaj expresiv și Oferă construcții care
proceselor din lumea reală
un vocabular de bază definesc șabloane pentru
(prin simulare și
simplu tratarea excepțiilor
optimizare)

8
Diferența dinte BPMN și alte limbaje pentru fluxuri de lucru

1. Stardard cu sintaxă și reguli de formare a modelelor valide

✓ Verificarea sintactică a modelelor se poate face pe parcurs, în timpul creării
modelelor sau se poate valida modelul la final ca precondiție pentru
simulare/automatizare.

2. Este ierarhic și permite imbricarea modelelor

3. Pentru fiecare element de modelare, BPMN definesc multe atribute adiționale
care nu apar în diagramă (spre exemplu, intrări/ieșiri sau listeneri).
✓ Acestea sunt parte a modelului BPMN, dar nu apar în diagramă. Mare parte a
acestor atribute sunt detalii necesare pentru automatizarea procesului folosind
un instrument dedicat (motor de procese).

✓ Majoritatea modelelor BPMN nu sunt create, însă, cu scopul de a fi executate.

9
Instrumente
specifice

10
Elemente ale limbajulului BPMN

11
Elemente ale limbajulului BPMN

Obiecte de flux (flow objects) reprezintă elementele de bază ale diagramei de proces.
La rândul lor, acestea se pot încadra în una din categoriile: Eveniment (event),
Activitate (activity), Poartă sau Ieşire (gateway).

Obiecte de conectare (connectig objects) au rolul de a conecta obiectele de flux între

ele sau cu alte tipuri de obiecte. Cele trei tipuri de obiecte de conectare sunt: Flux de
secvenţă (sequence flow), Flux de mesaje (message flow) şi Asociere (association).

Obiectele de partiţionare (swimlanes) stabilesc subgrafuri în fluxul de proces, cu

scopul de a separa logic anumite porţiuni ale acestuia, în funcţie de entităţile
participante la realizarea procesului. Ele pot fi de două tipuri: Container (pool) şi
Culoar (lane).

12
Elemente ale limbajulului BPMN

Datele (data) sunt necesare pentru a scoate în evidenţă datele de care au nevoie
activităţile sau care sunt produse de acestea. Datele se pot încadra în patru categorii:
Obiect de date (data object), Date de intrare (data input), Date de ieşire (data output)
şi Date stocate (data store).

Artefactelete (artifacts) sunt create cu scopul de a oferi informaţii adiţionale în cadrul

unei diagrame. Există două tipuri de artefacte standard: Grupul (group) şi respectiv
Adnotările textuale (annotation), dar atât limbajul, cât şi instrumentele de modelare
oferă posibilitatea de a adăuga orice alte artefacte personalizate de utilizator
necesare pentru înţelegerea modelului.

13
1. Obiecte de flux
 Reprezintă elementele grafice principale care definesc
comportamentul unui proces.
 Tipuri de obiecte de flux: Task
 Activitate - termen generic pentru a desemna ceva ce se
realizează în cadrul unui proces. Activităţile pot fi atomice Sub-Process
(acţiuni ) sau non-atomice (compuse). +
 Eveniment: ceva ce se întâmplă în timpul unui proces de
afaceri. Aceste evenimente afectează fluxul unui model şi au,
de obicei, o cauză (declanşator) sau un impact (rezultat).
Există trei tipuri de evenimente, pornind de la momentul în
care acestea afectează fluxul:

 Poartă: Elemente de modelare folosite pentru a controla

divergenţa sau convergenţa unor fluxuri de activităţi. Sunt
considerate elemente de decizie.
14
Acţiuni
Acţiunea este o activitate atomică ce nu mai poate fi descompusă pentru
a-i descrie comportamentul intern.

15
Subprocese
 Sunt sunt activităţi compuse incluse în interiorul unui proces.
 Pot fi imbricate în mod ierarhic până la orice nivel de detaliere.
este necesar pentru a descrie complet un proces.
 Pot fi reprezentate atât în mod condensat, cât şi extins.
 Orice descriere extinsă a unui subproces trebuie să conţină
evenimente de început şi de sfârşit pentru care nu se specifică
un comportament particular.

16
Evenimente
 Evenimentele sunt elemente care nu au durată.
 Exemple de evenimente:
▪ Sosirea unui mesaj, cum ar fi e-mail sau scrisoare
▪ Se ajunge la un anumit moment în timp (“începutul lunii”, “ora
10.00”).
▪ Trece o anumită perioadă de timp (“două zile”, “timp de coacere
complet”)
▪ O condiție devine adevărată (“Temperatura externă este de cel puțin
30°C”)
▪ Se produce o eroare (“Mesajul nu poate fi livrat”)

17
Categorii de evenimente
 Se reprezintă ca cercuri cu centrul gol pentru a permite folosirea de
marcatori interni pentru a diferenția diferiți declanșatori sau rezultate.
1. Eveniment de început care recepţionează un mesaj.
2. Eveniment intermediar care recepţionează un mesaj.
3. Eveniment intermediar care trimite un mesaj.
4. Eveniment final care trimite un mesaj.
5. Eveniment de început care recepţionează un mesaj fără a întrerupe o
altă activitate.
6. Eveniment intermediar care recepţionează un mesaj fără a întrerupe o
altă activitate.

18
Calificatori pentru evenimente- 1

19
Calificatori pentru evenimente -2

20
Evenimente de început
Eveniment de început necalificat. Declanșatorul nu este
important, nu se cunoaște sau poate fi dedus din context

Eveniment de început care așteaptă să se ajungă la un

anumit moment de timp

Eveniment de început care așteaptă primirea unui mesaj

Eveniment de început care are loc atunci când este

îndeplinită o condiție

Evenimente de început cu declanșatori

multipli: SAU – o singură condiție
îndeplinită, ȘI – toate condițiile îndeplinite
21
Evenimente intermediare
De obicei, evenimentele intermediare sunt modelate atunci când:
1. Un eveniment relevant pentru alți participanți este declanșat în cadrul unui
proces (de exemplu, este trimis un mesaj sau un semnal).
2. Există o reacție la un eveniment în cadrul unui proces (de exemplu, atunci când
este primit un mesaj sau se ajunge la un anumit moment de timp timp).
3. Se dorește modelarea unor excepții sau posibile erori ale sistemului.

22
Evenimente de tip eroare și ecaladare
 Evenimentele intermediare de eroare nu pot fi utilizate în fluxuri de secvențe
normale, ci doar atașate la limitele unei activități.
 În timp ce evenimentele de eroare sunt utilizate în principal pentru probleme
tehnice, evenimentele de escaladare identifică probleme la nivelul organizației,
de exemplu, dacă o sarcină nu este finalizată, un obiectiv nu este atins sau nu se
realizează un acord necesar.

23
 Porți - categorii

 Controlează fluxul de proces

 Direcționează logica sistemului

➢ Nu efectuează acțiuni/activități

➢ Nu iau decizii, dar pot testa

decizii

24
Porţi exclusive
 Cunoscute şi sub denumirea de decizii, sunt puncte din interiorul unui
proces de afaceri unde fluxul de secvenţe poate urma una dintre două sau
mai multe căi alternative.
 Numai una dintre posibilele căi de ieşire poate fi urmată atunci când
procesul este rulat. Corespunde unui „SAU exclusiv” logic.
 Se folosesc pentru divergența sau convergența fluxurilor mutual exclusive.
Conditie 1
Actiune 1

Conditie 2
Actiune 2
Verifica

Altfel Poartă exclusivă convergentă

Actiune 3

25
Porţi exclusive – reprezentare (1)

Reprezentare având întrebarea în

interiorul porții

Reprezentare având condiții

pe fluxuri

26
Porţi exclusive – reprezentare (2)
Reprezentare folosind perechi de porți

Nu este recomandat Preferabil

Porțile reprezintă doar logică procedurală

Incorect Corect
27
Porţi paralele
 Crează fluxuri de ieşire paralele fără a verifica nicio condiţie care să ducă la
declanşarea acestora.
 Sunt folosite pentru a sincroniza (combina) fluxuri paralele sau pentru a
desemna începutul unor fluxuri paralele.
 În acest fel se reprezintă executarea activităţilor concurente. Nu este
specificată o ordine a execuției activităților, acestea pot fi executate și
simultan.
 Corespunde unui „ȘI” logic.

28
Logica porților paralele

O poartă paralelă divergentă duplică jetonul

O poartă paralelă convergentă așteaptă toate jetoanele care

sosesc și le îmbină într-un singur jeton
29
Porţi inclusive
 Porţile inclusive pot declanşa mai mult de un rezultat, deci pot avea mai
multe fluxuri de ieşire.
 Toate condiţiile de ieşire sunt evaluate indiferent dacă există deja unul sau
mai multe fluxuri de ieşire ale căror condiţii au fost evaluate anterior ca
fiind adevărate.
 În cadrul unui model acestea sunt urmate, de obicei, de poarta inclusivă de
îmbinare corespunzătoare.
 Corespunde unui „SAU inclusiv” logic.

30
 Logica porților inclusive

Toate variantele selectate

Două variante selectate

O variantă selectată

O poartă inclusivă știe întotdeauna câte și ce fluxuri de secvențe au fost selectate. Deci,
știe ce jetoane sunt așteptate de poarta convergentă înainte de a putea îmbina jetoanele.

Realizați o paralelă între porțile convergente inclusive și cele exclusive și paralele pentru cele trei cazuri. 31
Porți inclusive – cazuri particular (1)

Unul dintre fluxuri nu ajunge la poarta convergentă

32
Porți inclusive – cazuri particular (2)

Convergența fluxurilor provenind de la o combinație de porți de tipuri deferite

33
Porţi complexe
 Se folosesc atunci când este necesară modelarea unui comportament care
presupune condiţii de sincronizare care nu pot fi descrise prin intermediul
mecanismelor prezentate anterior.
 Pot avea asociate oricâte reguli arbitrare definite de utilizator prin care să se
specifice modul în care va fi tratată sincronizarea sau divizarea fluxurilor de
secvenţe.

34
Porţi bazate pe evenimente
 Reprezintă un punct de ramificaţie al procesului unde fluxurile de ieşire se
bazează pe producerea unor evenimente şi nu pe evaluarea unor expresii
folosind date, aşa cum se întâmplă în cazul porţilor exlusive şi inclusive.
 Un eveniment specific care constă, de obicei, în primirea unui mesaj ce
determină calea care va trebui urmată.
 Decizia este luată de către un alt participant, pe baza unor date care nu sunt
accesibile procesului analizat.

35
2. Obiecte de conectare
 Un flux de secvenţă este utilizat pentru a descrie ordinea
elementelor din flux în modelele de proces şi coregrafie.
 Un flux de mesaj are rolul de a arăta fluxul de mesaje între doi
participanţi care sunt capabili să trimită şi să primească mesaje.
 O asociere de date este folosită pentru a arăta fluxul de informaţii
dintre activităţile unui proces de afacere.
 O asociere leagă artefactele cu alte elemente grafice ale BPMN.

36
Exemple de obiectele de conectare

37
Fluxuri de secvenţă
 Pot conecta următoarele tipuri de elemente: evenimente (de început, intermediare
şi de sfârşit), acţiuni, subprocese şi porţi,
 Limite ale unui flux de secvenţă:
 nu poate reprezenta o intrare pentru un eveniment de început;

 nu poate reprezenta o ieşire pentru un eveniment de sfârşit;

 nu poate conecta în mod direct o acţiune a unui proces cu o acţiune a unui

subproces, legătura trebuind realizată în mod corect între acţiune şi subproces;
 sunt permise numai în interiorul unui container, pentru interacţiunile dintre
containere trebuie utilizate fluxurile de mesaj;
 nu pot fi utilizate pentru a conecta artefacte la alte elemente ale modelului, în
acest caz fiind folosite asocierile;
 pot fi substituite prin evenimente intermediare de legătură, cu specificaţia că
ambele evenimente intermediare de legătură trebuie să aparţină aceluiaşi
container.
38
Utilizarea evenimentelor de legătură – exemple

Efectueaza Efectueaza
verificare verificare

39
Fluxurile de secvenţă condiţionale
 Atunci când conectează o poartă inclusivă sau exclusivă sau o activitate, un
flux de secvenţă poate defini o condiţie şi atunci va purta denumirea de flux
de secvenţă condițional. Semnul distinctiv este rombul.
 Există și fluxuri de secvență implicite, pentru situațiile în care nicio altă
condiție nu este îndeplinită.
 La folosirea fluxurilor de secvenţă condiţionale trebuie să se aibă
întotdeuna în vedere ca mulţimea condiţiilor reprezentate de fluxurile de
ieşire să conducă la un rezultat valid de fiecare dată când se realizează o
activitate. Client fidel
Solicita plata la
60 de zile

Stabileste conditii de Solicita plata la

plata pentru client 30 de zile

Solicita plata la
10 de zile
Client nou 40
Divergența fluxurilor exclusive fără a utiliza porți

Flux de secvență implicit la nivel de poartă și de activitate

41
Fluxuri de mesaj
 Un flux de mesaj este folosit pentru a reprezenta transmiterea de mesaje
între doi participanţi care sunt pregătiţi să trimită şi să primească aceste
mesaje. În BPMN, două containere separate din cadrul unei diagrame de
colaborare vor reprezenta cei doi participanţi.
 Opţional, fluxurile de mesaje pot fi extinse cu un obiect de tip mesaj
(messaje object), care va fi legat de fluxul de mesaj sau suprapus peste
acesta. Obiectul de tip mesaj descrie în mod explicit conţinutul
comunicaţiei între cei doi participanţi.
Client

Cotatie de pret Oferta

Mesaj care Mesaj care nu

initiaza initiaza
Furnizor

42
Asocieri de date
 Pentru a reprezenta fluxurile de date din cadrul unui proces, BPMN
foloseşte ca şi notaţie asocierea de date, care este o asociere direcţională.
Asocierile de date sunt folosite pentru a transfera date între procese sau
acţiuni.
 Asocierile de date nu produc nici un efect asupra fluxului de acţiuni din
cadrul procesului, rolul lor fiind acela de a arăta care este necesarul de date
pentru un anumit proces sau acţiune, precum şi care sunt datele pe care
acestea le produc sub formă de rezultate.

Raport de Concluzii
Cerere de analiza
achizitie
ACHIZTIE

Analizeaza
Trage concluzii
cererea
Cerere de achizitie Analiza cerere
primita incheiata
Propune respingere
sau aprobare
43
3. Obiecte de partiţionare
 Reprezintă un mecanism de organizare a activităţilor în
categorii vizuale separate în scopul evidenţierii diferitelor
capacităţi funcţionale sau responsabilităţi.
 Container (Pool): reprezintă un participant în proces. Implică
unităţi organizaţionale sau participanţi separaţi fizic.
 Culoar (Lane): este folosit pentru a organiza şi a împărţi activităţile.
Sunt plasate în interiorul unui container şi pot fi imbricate.

44
Participanţi
 Elementul de tip participant constituie o entitate
identificată la nivelul modelului de afacere, care:
 execută sau are anumite responsabilităţi în executarea
activităţilor din cadrul unui proces;
 joacă rolul de participant în cadrul unei colaborări.
 Din perspectiva limbajului BPMN, un participant este
reprezentat vizual sub forma unui container (pool)
 BPMN face distincţie între două niveluri de participare:
 unitatea organizaţională, care reprezintă grupul de interes intern
sau extern organizaţiei, precum compania sau departamentul;
 rolul asociat execuţiei unei activităţi, cum ar fi client, furnizor,
producător etc.

45
Containere
 Un container poate fi denumit după numele unui participant sau
după numele procesului în sine
 Reprezentarea unui container în jurul procesului este opțională în
diagrama de proces
 Chiar dacă nu există container într-o diagramă de proces, acesta,
de fapt, există, fiind implicit
 Se recomandă, însă, includerea containerelor deoarece oferă
claritate și ne permit să denumim procesul
Dapartament vanzari

Onorare comenzi
Banca

46
Fluxuri de secvenţă şi de mesaj
 Un container încapsulează secvenţa de activităţi a unui proces, ceea
ce înseamnă că fluxurile de secvenţă nu pot traversa graniţele unui
container.
 Numele containerului nu este obligatoriu să semnifice o unitate
organizaţională, acesta poate să desemneze şi numele procesului în
sine, cum ar fi “Recepţie produse” sau “Solicitare reparaţie”.
Client

Aduce produsul Primeste bon

Cere reparatie Preda produs
defect de receptie
Produsul nu mai
functioneaza
Service

Raporteaza Intocmeste bon Receptioneaza

Verifica produs
defectiuni de receptie produs

47
Partiţionarea unui container prin culoare
 Culoarele ajută la identificarea responsabilităţilor în cadrul unui
proces de afaceri.
 Pot reprezenta activități tehnologice sau umane.
 Culoarele se aplică doar activităților, nu și porților sau evenimentelor.
 Fluxul de secvenţă poate traversa culoarele pentru a duce la
îndeplinire activităţile specifice unui proces.

Refuza cererea
Vanzari

Primeste cerere Cerere refuzata

de produse NU Transmite
Calculeaza pret
oferta
Cerere onorata
Companie

DA
Depozit

Verifica stoc

Produse in stoc?
Management

Aproba discount

48
4. Date

 Când se execută un proces, acesta folosește și creează

date, informații, fișiere, documente etc.
 Un flux de secvențe este adesea însoțit de transfer de
date.
 De asemenea, unul din scopurile principale ale fluxului de
mesaje este schimbul de date.
 Datele sunt mecanisme prin care sunt evidenţiate datele
necesare sau produse de activităţi. Sunt conectate la alte
elemente prin asocieri de date.

49
Categorii de date
 Obiect de date - reprezintă informații care se transmit în interiorul procesului,
cum ar fi documente comerciale, e-mailuri sau scrisori. Pot fi fizice sau electronice.
Sunt frecvent utilizate pentru modelarea datelor în BPMN.
 Intrare date - o intrare externă pentru întregul proces; un fel de parametru de
intrare.
 Date de ieșire - rezultatul datelor întregului proces; un fel de parametru de
ieșire.
 Colecție de date - reprezintă o colecție de informații, de exemplu, o listă de
articole comandate. Se aplică celor trei categorii anterioare
 Date stocate – element în care în procesul poate citi sau scrie date; de exemplu,
o bază de date sau o colecție de dosare cu oferte. Persistă dincolo de durata de
viață a instanței procesului.

50
Categorii de date - exemplu

Date de intrare
Date de iesire

Desfacere
Date client
Factura

Produse comandate Produse in stoc? Aviz de insotire a

marfii
DA
Primeste Intocmeste Impacheteaza si
Verifica stoc Pregateste livrare
comanda factura incarca produse

NU

Instiinteaza client Plan de transport

BD Produse
Date stocate

51
Obiecte de date – notații alternative

Utilizarea ulterioară a unui obiecte de date

52
Date - stare
 În timpul transmiterii datelor printr-un proces, acestea își pot schimba starea pe
parcurs.
 Starea datelor apare între paranteze drepte sub numele acestora.

53
5. Artefacte

 Adnotări: mecanism folosit

pentru a adăuga informaţii
adiţionale în model.
 Grup: un element de grupare
folosit în scopuri de
documentare şi analiză care
nu afectează secvenţa de flux.

54
6. Tipuri de diagrame
 Un model de proces de afaceri nu este un concept uniform,
având notaţii singulare.
 Specificaţia BPMN 2.0 conţine patru tipuri de astfel de
modele, şi anume:
 diagrama de procese de afaceri – conţine un singur container
 diagrama de colaborare – mai multe containere
 diagrama de coregrafie
 diagrama de conversaţie
 Fiind cea mai detaliată dintre acestea, diagrama de procese
de afaceri este şi cea mai uzitată în practică, celelalte trei
tipuri de diagrame putând fi considerate o reprezentare
sintetică a cunoştinţelor specifice despre procesele de
afaceri

55
Recapitulare -1
1) Care sunt elementele de bază ale limbajului BPMN?
2) Evenimentele de început, sfârșit și intermediare au reprezentări
diferite. Cu ce simbol grafic se reprezintă un eveniment
intermediar?
3) Ce tip de structură de control din programare modelează
porțile exclusive?
4) Porțile paralele verifică îndeplinirea unor condiții?
5) În figura de la pagina 30 pot avea și transport aerian și
transport terestru, sau se exclud?
6) Pentru care tip de porți decizia este luată de pe baza unor date
care nu sunt accesibile procesului analizat?

56
Recapitulare- 2
7) Când folosim porțile complexe?

8) Ce tipuri de obiecte de conectare oferă limbajul?

9) Când folosim fluxurile de secvență? Dar pe cele de mesaj?

10) Prin ce se diferențiază containerele de culoare?

11) Fluxul de secvență poate traversa containere?

12) Ce tip de obiecte de date sunt “Produsele comandate” și “Plan

de transport” din figura de la pagina 51?

57
 ACADEMIA DE STUDII ECONOMICE BUCUREŞTI
FACULTATEA DE CIBERNETICĂ, STATISTICĂ ŞI INFORMATICĂ ECONOMICĂ

P RO I E C TA R E A S I S T E M E LO R
I N F O R M AT I C E

-CURS 9-

BUCUREȘTI
2020-2021
Proiectarea
sistemelor – partea I -

informatice
Cuprins

✓Aspecte generale ale proiectării sistemelor informatice

✓Principiul proiectării eşalonate a sistemelor informatice

✓Proiectarea mediului de execuție

✓Proiectarea arhitecturii sistemului informatic

1. Arhitectura client server

2. Arhitectura orientată pe servicii

✓Îmbunătățirea modelului de analiză

✓Proiectarea interfețelor
 Aspecte generale ale proiectării sistemelor
informatice

• Proiectarea sistemului informatic constă în:

➢ stabilirea soluţiilor logice
➢ specificarea din punct de vedere fizic a componentelor
noului sistem.
• Proiectarea se bazează în principal pe rezultatele
obţinute din cele două grupe de activităţi premergătoare:
➢ definirea soluţiei de realizare a noului sistem
➢ modelarea noului sistem.
Obiectivele proiectării

Activități de analiză
Obiective: să înțeleaga:
• Evenimentele si
procesele din
companie
• Activitățile sistemului
și cerintele de
procesare
• Stocarea și necesarul
de informații

Activitati de
Modele de analiza proiectare
Obiective:
• Să definească, să
organizeze, să
Documente
structureze
componentele
sistemului soluție
Aspecte generale ale proiectării sistemelor
informatice

• Unele metodologii împart proiectarea sistemelor

informatice în:
A. proiectare generală/proiectare de ansamblu /
conceperea sistemului informatic
B. proiectarea de detaliu – include proiectarea detaliilor
specifice ale programelor:
i. Proiectarea fiecarui caz de utilizare
ii. Proiectarea bazei de date
iii. Proiectarea interfețelor cu utilizatorul si cu alte sisteme
iv. Proiectarea controlului și a securității

• În cadrul acestor etape, sistemul este proiectat din

punct de vedere logic şi din punct de vedere fizic,
separat sau nu.
Principiul proiectării eşalonate a sistemelor
informatice
• La stabilirea ordinii de prioritate în abordarea structurilor
sistemului informatic pot fi avute în vedere următoarele
criterii:
➢ prioritatea obiectivelor componente;
➢ asigurarea legăturilor între componente;
➢ disponibilitatea resurselor (limita fondurilor ce pot fi alocate în
timp pentru realizarea sistemului informatic;
➢ nivelul de dotare cu tehnică de calcul existent în etapa de
concepere şi cel prevăzut a fi atins în timp;
➢ forţele de proiectare pe care le va antrena proiectul;
➢ personalul de specialitate existent şi în pregătire, la unitatea
beneficiară, necesar pentru implementarea şi exploatarea
curentă a sistemului informatic).
Întrebări cheie ale activității de proiectare
Activitate de proiectare
Proiectarea mediului de execuție
Proiectarea arhitecturii aplicației și
software-lui
Proiectarea interfețelor cu alte sisteme
Proiectarea bazei de date
Proiectarea controalelor și securitatii
sistemului
Intrebare
A fost specificat in detaliu mediul de
execuție software cu toate opțiunile?
Au fost specificate in detaliu toate
elementele software-lui si cum va fi
realizat fiecare caz de utilizare?
A fost specificat in detaliu modul în care
sistemul va comunica cu toate celelalte
sisteme din interior/exteriorul
organizației?
Au fost specificate în detaliu toate
cerințele de stocare ale datelor, inclusiv
toate elementele schemei?
Au fost specificate în detaliu toate
elementele pentru a asigura siguranța
sistemului, securitatea și protectia
datelor?
I. Proiectarea mediului

• MEDIUL reprezintă toate tehnologiile necesare

pentru a susține aplicația software
• Calculatoare server sau desktop
• Dispozitive mobile, sisteme de operare
• Facilități de comunicație, de intrare și de iesire
• Se mai numește și Arhitectura tehnică
II. Proiectarea arhitecturii aplicaţiei şi software-
lui

• Împarțirea sistemului în subsisteme

• Definirea arhitecturii software
• Pe trei niveluri sau model-view-controller
• Proiectarea detaliată a fiecarui caz de utilizare
• diagrame de clase de proiectare
• diagrame de secvențe
• diagrame de stări
III. Proiectarea interfeţelor cu utilizatorii

• Proiectarea dialogului pleacă de la cerințe

• Fluxul de activități din cazurile de utilizare
• Diagramele de secvență ale sistemului
• În prezent este necesară proiectarea de
interfețe pentru diverse medii și dispozitive:
• Telefoane smart
• Tablete, iPad, etc
Proiectarea interfeţelor cu alte sisteme

• Sistemul informatic interacționează cu alte

sisteme interne sau externe, fiind necesară
integrarea acestora
• Conectarea la alte sisteme se poate realiza în
multiple feluri:
• Se pot salva datele de alte sisteme
• Se pot utiliza date salvate din alte sisteme
• Se pot face solicitări de informații în timp real
• Se poate apela la servicii software
Identificarea interfețelor sistemului

• Intrări și ieșiri cu intervenție umană minimă, cu

nivel ridicat de automatizare
• acestea sunt capturate de dispozitive (scanere, senzori
etc.) sau generate de persoane care inițiază un proces
care se desfășoară fără intervenții umane suplimentare
• Intrări și ieșiri de la/către alte sisteme:
• acestea sunt interfețe directe cu alte sisteme
informatice, formatate, de obicei, ca mesaje de rețea
• Intrări și ieșiri către baze de date externe:
• Acestea pot furniza intrări sau accepta ieșiri de la un
sistem
IV. Proiectarea bazei de date

• Se pleaca de la modelul claselor domeniului (ERD)

• Se alege structura bazei de date
• De obicei se lucreaza cu baze de date relaționale
• pot există platforme care lucrează cu baze de date orientate
obiect sau sisteme NoSQL
• Se proiectează arhitectura BD (distribuită, etc)
• Se proiectează schema bazei de date
• Tabelele și coloanele în relațional
• Se proiectează restricțiile de integritate referențială
• Referințe prin chei externe
V. Proiectarea securităţii şi controalelor

• Scopul este de a proteja bunurile companiei

• Este un element crucial in Internet și rețele
wireless
• Este nevoie să de proiecteze controale la nivel
de:
• Interfața cu utilizatorul
• Aplicație
• Bază de date
• Rețea
I. Proiectarea arhitecturii tehnice (mediului)

1. Proiectarea unui sistem cu implementare

internă
a) Sisteme software stand alone - care rulează pe un
singur dispozitiv, fără conectare la rețea
b) Sisteme software bazate pe o rețea internă
➢ Arhitectura client-server, rețea LAN
➢ Aplicații desktop și aplicatii bazate pe browser
c) Arhitecturi client server pe trei niveluri
➢ Nivelul datelor, nivelul aplicației și nivelul prezentare
➢ Aplicații desktop și aplicații bazate pe browser
I. Proiectarea arhitecturii tehnice

2. Proiectare pentru implementare externă

• Configurare pentru implementare pe Internet – cu
avantaje și riscuri
• Alternative de găzduire pentru implementare pe
Internet
➢ Colocație
➢ Servicii de management
➢ Servere virtuale
➢ Cloud computing
• Diversitatea dispozitivelor client
➢ Laptop, tablete si notebook, telefon smart etc
 Configuraţie pentru implementare pe Internet

• Avantaje
➢ Accesibilitate număr mare de utilizatori potențiali
➢ Costuri reduse ale comunicației
➢ Standarde utilizate pe scara largă – standarde Web arhicunoscute
• Probleme potențiale:
➢ Securitate – breșe de Securitate pe serverele Web, atacuri hacker
➢ https – Hypertext Transfer Protocol Secure
➢ TLS – Transport Layer Security – ver. Avansata a protocolului de retea SSL
➢ Volumul datelor trasmise prin rețea dacă traficul este încarcat,
volumul datelor transmise și durata sunt ridicate
➢ Schimbarea standardelor—Stardardele Web se schimbă rapid
(funcționalitate vs compatibilitate)
 Atribute ale opțiunilor de găzduire

OPȚIUNI DE GĂZDUIRE

Opțiuni serviciu Colocare Managed Servere virtuale Cloud computing

services
Serviciul oferă găzduire și Da Da Da Da
infrastructură
Clientul deține calculatorul Da Poate Nu Nu

Clientul gestionează Da Nu Posibil Nu

configurația calculatorului
Scalabilitate Clientul adaugă Clientul adaugă Clientul cumpără servere Clientul cumpără
calculatoare calculatoare virtuale mai mari sau mai multe capacitate suplimentară
Mentenanță Oferită de client Oferită de gazdă Oferită de gazdă Oferită de gazdă

Backup și recuperare Oferită de client Oferită de gazdă Disponibilă Disponibilă

II. Proiectarea arhitecturii sistemului informatic

• Cele mai cunoscute tipuri de reţele sunt:

➢Reţea punct la punct (bus);
➢Reţea inel (ring);
➢Reţea stea (star);
➢Reţea ierarhică.
• După alegerea tipului de reţea, echipa de analiză
trebuie să identifice protocolul de comunicaţie. Cele
mai cunoscute protocoale de comunicaţii sunt:
➢TCP/IP: Este un protocol indicat în cazul utilizării unei reţele
Ethernet sau în cazul în care calculatoarele din reţea au
arhitecturi diferite;
➢SNA: Este utilizat, în general pentru conectarea mainframe-
urilor IBM.
1. Arhitectura client/server
• Arhitectura client/server este un ansamblu de trei componente
principale: server, client şi o reţea care conectează
calculatoarele client la servere pentru a colabora la
îndeplinirea sarcinilor.
• Tipurile de aplicaţii client/server sunt:
➢ Sisteme cu baze de date
➢ Poşta electronică (E-mail)
➢ Sisteme de tip „groupware“
➢ Sisteme moştenite

• O arhitectură distribuită presupune existenţa unor baze de

date multiple (care se găsesc pe calculatoare distincte) şi a
unor aplicaţii care manipulează datele de la diferite staţii de
lucru locale cu ajutorul unor sisteme de gestiune a bazelor de
date (SGBD).
Proiectarea unei arhitecturi client-server
triplu stratificată
➢ Conține nivelul datelor, nivelul domeniului problemei, nivelul
prezentării

➢ Potrivit pentru aplicații desktop și aplicații web

➢ Unul dintre avantajele arhitecturii client-server este acela că permite

cu ușurință dezvoltarea aplicațiilor cu arhitectură triplu stratificată
Model View Controller (MVC)

• Este un model arhitectural utilizat în ingineria software.

• Ajută la scrierea de cod mai bine organizat și mai ușor
de gestionat.
• A fost intens folosit și testat pentru o varietate de
limbaje de programare (Java, PHP, ASP.NET etc.).
• Reprezintă un cadru de lucru important pentru
construirea aplicațiilor web.
• Separarea oferită de MVC ajută la gestionarea
aplicațiilor complexe și simplifică dezvoltarea
aplicațiilor în echipă.
MVC Model-View-Controller

Model: componentă centrală a MVC,

gestionează datele, logica și
constrângerile unei aplicații. Acesta
surprinde comportamentul unei aplicații.
View: responsabil pentru afișarea tuturor
datelor sau a unei părți a acestora către
utilizator. Formatează și prezintă datele
preluate de la model către utilizator.
Controller: controlează interacțiunile dintre
Model și View. Funcționează ca o interfață
între modelele asociate, vizualizări și
dispozitivele de intrare.
2. Arhitectura orientată pe servicii (SOA -
Service Oriented Architecture)

▪ Aplicațiile moderne sunt construite din componente software bazate

pe standarde de interacțiune:

▪ Simple Object Access Protocol (SOAP) și

▪ Java Platform Enterprise Edition (Java EE).

▪ SOA se bazează pe un mecanism de cerere/răspuns convenţional:

un consumator de serviciu invocă un furnizor de serviciu prin reţea şi
aşteaptă până când se va realiza operaţia la furnizor.
SOA- Service Oriented Architecture
▪ SOA divide o aplicaţie în două părți:

▪ Un coordonator de serviciu, care reprezintă funcţionalitatea la utilizator

şi

▪ Furnizorii de servicii, care implementează funcţionalitatea.

▪ În timp ce coordonatorul tinde să fie unic pentru o aplicaţie particulară,

un serviciu poate fi reutilizat şi partajat de multiple aplicaţii compozite.

▪ Coordonatorul serviciului, în mod explicit, specifică şi invocă serviciile

dorite.
Modele de analiza și modele de proiectare

ANALIZA PROIECTARE

Diagrame de Diagrame de
Diagrame de Diagrame de
cazuri de clase -
clase pachete
utilizare proiectare

Descrieri ale Diagrame de Schema bazei

Diagrame de
cazurilor de secvente de date
secvente
utilizare

Diagrame de Diagrame de Interfata cu Diagrama de

stari activitati utilizatorul componente

Securitatea si
Diagrama de
controlul
desfasurare
sistemului
Modele de analiza și modele de proiectare

ANALYSIS DESIGN
Scopul modelării

• După analiza sistemului, trecem la proiectarea

sistemului pentru a:
• Facilitarea înțelegerii corecte a sistemului;
• Eliminarea informațiilor despre redundanța operațională;
• Reducerea timpului de execuție pentru diverse interogări și
actualizări ale bazei de date;
• Reducerea timpului de așteptare al clientului.

• Odată proiectată arhitectura sistemului se poate

trece la reiterarea și îmbunătățirea modelului de
analiză.
Realizarea cazurilor de utilizare
• Proiectarea și implementarea cazurilor de utilizare
• Diagrama de secvență - este extinsă pornind de la diagrama de secvență a
sistemului, adăugând un controller și clase de domeniu;
• Diagrama claselor de proiectare - este extinsă pornind de la modelul claselor
de domeniu și este actualizată pe baza diagramelor de secvență
• Mesajele (apelurile) primite de un obiect ar trebui să devină metode ale clasei
respective
• Definițiile clasei - sunt scrise în limbajul de programare ales pentru
implementarea claselor de proiectare și controller.
• Clase de interfață utilizator - formulare sau pagini adăugate pentru a gestiona
interfața dintre actori și clasele de tip controller.
• Clasele de acces BD - acestea sunt adăugate pentru a gestiona cererile pentru
interogarea sau salvarea datelor în DB
• Proiectare detaliată a modelului static
• O versiune detaliată a diagramei de clase este proiectată, incluzând vizibilitatea
de navigare pentru asociații.
• Pe baza diagramelor de secvență, semnătura metodelor clasei este completată
• Soluția este partiționată în pachete (elemente de grupare), după cum se
consideră necesar
Proiectarea diagramei de clase

Stereotipurile sunt adăugate pentru clase

• Clase persistente - o clasă ale cărei obiecte trebuie să existe
după oprirea sistemului
• Clasa entitate - un identificator pentru o clasă din domeniul
problemei de business
• Limită / clasa de vizualizare - o clasă situată la limita automată a
unui sistem, cum ar fi formular de intrare sau o pagină Web
• Clasa de control - o clasă care mediază între clase de graniță și
entitate, acționând ca un panou de control între nivelul
utilizatorului (vizualizare) și nivelul de afaceri
• Clasa de acces la date - o clasă care este utilizată pentru a primi
sau trimite date dintr-o bază de date
Diagrama detaliata a claselor

• Se parcurg pe rand cazurile de utilizare

• Se aleg clasele domeniului care sunt implicate in cazul de
utilizare; se verifica preconditiile si postconditiile pentru
completarea acestora
• Se adauga o clasa controller care sa fie responsabila pentru
cazul de utilizare
• Se determina cerintele de vizibilitate a navigarii
• Se completeaza atributele fiecarei clase cu vizibilitate si tip
• Observatie: de multe ori asocierile si multiplicitatile sunt
eliminate din diagrama, pentru a pune accentul pe navigare,
dar ele se pot pastra
 Vizibilitatea navigarii

• Abilitatea unui obiect de a vedea si interactiona cu alt obiect

• Realizata prin adaugarea intr-o clasa a unei variabile referinta
la obiect
• Apare ca o sageata pe capatul asocierii – Clientul poate vedea
si interactiona cu Vanzare
Reguli pentru navigabilitate

• Asocierile unu la multi care indica o relatie

superior-subordonat asigura navigarea de la
superior la subordonati
• Asocierile obligatorii in care obiectele dintr-o clasa
nu pot sa existe fara obiectele din alta clasa
asigura de obicei navigarea de la clasa mai
independenta la cea mai dependenta
• Cand un obiect are nevoie de informatii de la un alt
obiect, ar putea fi nevoie de o sageata de navigare
Metodele claselor

• Se poate folosi tehnica CRC – Class,

Responsibility, Collaboration cards
• Care sunt responsabilitatile unei clase si cum
colaboreaza cu alte clase pentru a realiza cazul de
utilizare
• Se obtin prin brainstorming
• Se pot folosi diagramele de secventa detaliate –
fiecare mesaj receptionat de un obiect al unei
clase trebuie sa aiba in corespondenta o metoda
in clasa respectiva
Exemplu de carduri CRC
 Proiectarea interfețelor

• După completarea diagramelor de cazuri de utilizare și

elaborarea primei versiuni stabile de diagrame de clasă și
interacțiune, se recomandă implementarea unui prototip
al interfeței sistemului.
• Acest prototip se numește prototip de interfață,
deoarece are rolul de:
• Rafina relațiile dintre actori și clase de interfață;
• Obține feedback de la client (client) cu privire la aspectul
vizual al aplicației.
Specificarea cerințelor interfeței
• Specificațiile interfeței includ detalii despre ceea ce este necesar
pentru ca actorul să interacționeze cu sistemul: nume, titlu și câteva
informații descriptive despre modul în care interfața este utilizată de
actor.
• Astfel, un document cu specificații de interfață include:
• Obiectivele actorului în interacțiunea cu sistemul (documentate și în
cazurile de utilizare),
• Lista interfețelor (bazate pe varietatea și numărul de interacțiuni pe care
un actor le va avea cu sistemul) și
• Navigare și dependențe (bazate pe fluxurile de proces documentate în
cazuri de utilizare, dar acum revizuite pe baza interfețelor).
• Standardul UML joacă un rol minim în modelarea unei UI. Nu există o
diagramă UML care să modeleze o interfață.
• UI-urile pot fi specificate folosind șabloane
Șablonul de specificații a interfeței
• Identificator interfață
< Acesta reprezintă numărul și denumirea interfeței>
• Actori
< O listă a actorilor care interacționează cu sistemul prin
această interfață>
• Cazuri de utilizare
< Lista cazurilor de utilizare în care apare această interfață>
• Scurtă descriere
< Descrierea în cateva rânduri a interfeței>
 Proiectarea interfețelor

• Primul pas - investigarea așteptărilor actorilor

referitor la interfață prin completarea chestionarelor
specifice constând din următoarele întrebări:
• Ce nivel de pregătire (informatică) trebuie să aibă actorul pentru
a realiza o anumită funcționalitate?
• Are actorul experiență de lucru în medii bazate pe ferestre?
• Are actorul experiență în utilizarea altor sisteme automate de
modelare a proceselor?
• Este necesar să consulte documente / cataloage în paralel cu
utilizarea aplicației?
• Actorul dorește să implementeze facilități de „salvare /
restaurare”?
Proiectarea interfețelor

• Obiectivele prototipului sunt:

• Stabilirea cerințelor interfeței pentru funcționalitățile
cheie ale aplicației;
• Acesta demonstrează clientului (într-o formă
vizuală) că cerințele proiectului au fost bine înțelese
și pot fi realizate;
• Începerea fazei de dezvoltare a elementelor
standard ale interfeței.
Detalii pentru proiectarea interfeței

• Fiecare interfață are datele sale descrise ca atribute în cadrul claselor /

programelor care manipulează și afișează aceste date. Aceste interfețe
sunt proiectate și dezvoltate iterativ. De exemplu, o schiță inițială în prima
iterație, nu oferă detalii specifice de proiectare, cum ar fi culoarea,
dimensiunea căsuțelor de text și așa mai departe.
 Proiectarea interfețelor

• Hărți cu structura ecranului (diagrame) sunt utilizate pentru

a descrie fluxul aplicației urmând principalele moduri de
utilizare.
• Reprezentare:
• Forme pătrate pentru reprezentarea ferestrelor modale (necesită
un răspuns al utilizatorului pentru a continua o activitate).
• Forme pătrate cu colțuri rotunjite pentru reprezentarea ferestrelor
nemodale
• Direcția de trecere arată calea de navigare a ferestrei.
Specificarea fluxului de interfețe utilizator -
harta de navigare pentru un doctor
• Diagramele de flux UI, numite ocazional și storyboard-uri, diagrame de
navigare a ecranului sau hărți de navigare, modelează relațiile și
dependențele dintre interfețele utilizator. Deoarece UML oferă o diagramă
de activități ca diagramă de flux, putem crea această hartă de navigare.
Ecranele sunt reprezentate de obiecte în această diagramă de activitate.
Ferestre care conţin tab-uri

Diagramă de structură a
ecranului
Proiectarea interfețelor pentru aplicații mobile
cu machete

Legenda descriind
scopul principal al
ecranului
Backround:
conectivitate și
informații adiacente

Legenda descriind Legenda descriind

scopul principal al ecranul secundar
ecranului

Separator al
Identificarea funcționalităților din
utilizatorului ecran

Functionalități
personalizate
pentru tuilizator

Functionalități cheie
personalizate pentru
utilizator
Proiectarea interfețelor pentru aplicații mobile
cu storyboard-uri

Formular
afisat cu
detalii ale
Daca butonul cerere
‘Cerere grup nou’ Buton afisat
este selectat pt
confirmare
/respingere

Se afișeaza
Este grupurile de
Antrenor antrenori.
selectată
Avem butoane Daca
Meniu opțiunea pt adaugarea
Logare ‘Adaugă
’Grupuri’ unui nou grup
principal grup’
și dc a fost
este
facută de client
o cerere pt selectat
grup nou Formular
afisat pt
adaugare
detalii grup
nou dorit de
antrenor
Considerații privind designul interfeței cu
utilizatorul

• Analistul de afaceri este inițial responsabil pentru specificațiile UI.

Aceste specificații sunt analizate în timpul proiectării UI pentru a
crea clase de interfață detaliate și implementabile.
• GUI-urile rezultate pot fi apoi organizate în funcție de actorii
(utilizatorii) care le vor folosi.
• GUI-urile sunt de obicei derivate din suportul grafic existent oferit
de mediul de dezvoltare: ferestre, bare de defilare și butoane radio
etc. Un obiect de tip FORM este de obicei disponibil și oferă cele
mai multe funcționalități GUI.
• Interfețele pot fi, de asemenea, create și reutilizate de către
designeri: o clasă de interfață comună este creată care reprezintă
fereastra principală pentru interacțiunea actorilor. Apoi, restul
interfețelor necesare acelui actor pot moșteni funcționalitatea
comună oferită de clasa de interfață comună
Derivarea modelării interfețelor: ierarhia de
moșteniri
• Toate clasele de graniță sunt derivate dintr-o clasă principală HMSmainForm
(bazată pe clase furnizate de mediul de dezvoltare). Clasele specifice
actorului care furnizează interfețele comune pentru actor sunt
StaffCommonForm și PatientCommonForm.
Treisprezece principii pentru proiectarea
modului de afișare
• Christopher Wickens și colab. au definit 13 principii ale
designului în cartea lor An Introduction to Human
Factors Engineering (2004)
• pot fi utilizate pentru proiectarea eficientă a modului de
afișare.
BENEFICII POTENȚIALE
• o reducere a erorilor și a timpului de pregătire necesar,
• o creștere a eficienței,
• o creștere a satisfacției utilizatorilor
Sunt grupate în 4 categorii
 a. Principii bazate pe percepție
1. Faceți afișajele lizibile (sau audibile). Legibilitatea unui afișaj este critică și
necesară pentru proiectarea unui afișaj utilizabil.
2. Evitați limitele absolute ale judecății. Nu cereți utilizatorului să determine nivelul
unei variabile pe baza unei singure variabile senzoriale (de exemplu, culoare,
dimensiune, sunet).
3. Procesare de sus în jos (top-down). Semnalele sunt cel mai probabil percepute și
interpretate în conformitate cu ceea ce se așteaptă pe baza experienței
utilizatorului. Dacă un semnal este prezentat contrar așteptării utilizatorului, poate fi
necesară prezentarea mai multor dovezi fizice ale semnalului pentru a fi înțeles
corect.
4. Creșterea redundanței. Dacă un semnal este prezentat de mai multe ori, este
mai probabil să fie înțeles corect. Acest lucru se poate realiza prin prezentarea
semnalului în forme fizice alternative (de exemplu, culoare și formă, voce și
imprimare etc.), deoarece redundanța nu implică repetarea..
5. Asemănarea provoacă confuzie: Utilizați elemente distincte. Semnalele care par
a fi similare vor fi probabil confundate. Raportul de caracteristici similare la
caracteristici diferite face ca semnalele să fie similare. De exemplu, A423B9 este
mai asemănător cu A423B8 ​decât 92 este cu 93.
b. Principiile modelului mental

6. Principiul realismului pictural. Un afișaj ar trebui să arate ca

variabila pe care o reprezintă (de exemplu, temperatura ridicată pe
un termometru arătat ca un nivel vertical mai mare). Dacă există mai
multe elemente, ele pot fi configurate într-o manieră care ar arăta la
fel ca în mediul reprezentat.
7. Principiul piesei în mișcare. Elementele în mișcare ar trebui să se
deplaseze într-un model și o direcție compatibile cu modelul mental
al utilizatorului cu privire la modul în care se mișcă efectiv în sistem.
De exemplu, elementul care se mișcă pe un altimetru ar trebui să se
deplaseze în sus, odată cu creșterea altitudinii.
c. Principii bazate pe atenție
8. Minimizarea costului accesului la informații sau al interacțiunii. Atunci când
atenția utilizatorului este redirecționată de la o locație la alta pentru a accesa
informațiile necesare, există un cost asociat în timp sau efort. O interfață ar
trebui să reducă la minimum acest cost, permițând localizarea surselor frecvent
accesate în cea mai apropiată poziție posibilă. Cu toate acestea, nu trebuie
sacrificată lizibilitatea adecvată pentru a reduce acest cost.
9. Principiul compatibilității proximității. Atenție împărțită între două surse de
informații poate fi necesară pentru finalizarea unei sarcini. Aceste surse trebuie
să fie integrate mental și sunt definite pentru a avea o proximitate mentală
strânsă. Costurile de acces la informații ar trebui să fie scăzute, ceea ce poate fi
obținut în mai multe moduri (de exemplu, apropierea, creare unei legături prin
culori, modele, forme etc.). Cu toate acestea, apropierea excesivă a elementelor
de afișat poate fi dăunătoare provocând prea multă aglomerație.
10. Principiul resurselor multiple. Un utilizator poate prelucra mai ușor
informațiile prezentate prin diferite resurse. De exemplu, informațiile vizuale și
auditive pot fi prezentate simultan, în loc să fie prezinte exclusiv vizual sau
auditiv.
d. Principiile bazate pe memorie

11. Înlocuiți memoria cu informații vizuale: cunoștințe din lume. Un utilizator nu

trebuie să rețină informații importante doar în memoria de lucru sau să le
recupereze din memoria pe termen lung. Un meniu, o listă de verificare sau un
alt afișaj poate ajuta utilizatorul ușurând utilizarea memoriei sale. Utilizarea
cunoștințelor memorate de un utilizator și cunoștințele din lume trebuie să fie
echilibrate pentru un design eficient.
12. Principiul ajutorului predictiv. Acțiunile proactive sunt de obicei mai eficiente
decât acțiunile reactive. Un afișaj ar trebui să încerce să elimine sarcinile
cognitive care necesită resurse și să le înlocuiască cu sarcini perceptive mai
simple pentru a reduce utilizarea resurselor mentale ale utilizatorului. Acest
lucru va permite utilizatorului să se concentreze asupra condițiilor actuale și să
ia în considerare posibile condiții viitoare. Un exemplu de ajutor predictiv este un
indicativ rutier care afișează distanța până la o anumită destinație.
13. Principiul consecvenței. Obiceiurile vechi de la alte afișaje se transferă cu
ușurință pentru a sprijini procesarea de afișaje noi dacă sunt proiectate în mod
consistent. Memoria unui utilizator pe termen lung va declanșa acțiuni care se
așteaptă să fie adecvate. Un design trebuie să accepte acest fapt și să utilizeze
consecvență între diferite afișaje
 ACADEMIA DE STUDII ECONOMICE BUCUREŞTI
FACULTATEA DE CIBERNETICĂ, STATISTICĂ ŞI INFORMATICĂ ECONOMICĂ

P RO I E C TA R E A S I S T E M E LO R
I N F O R M AT I C E

-CURS 11-

BUCUREȘTI
2020-2021
Proiectarea
sistemelor – partea II -

informatice
Cuprins

✓Proiectarea interfețelor

✓Proiectarea bazei de date

✓Proiectarea diagramelor de implementare

 Proiectarea interfețelor

• După completarea diagramelor de cazuri de utilizare și

elaborarea primei versiuni stabile de diagrame de clasă și
interacțiune, se recomandă implementarea unui prototip
al interfeței sistemului.
• Acest prototip se numește prototip de interfață,
deoarece are rolul de:
• Rafina relațiile dintre actori și clase de interfață;
• Obține feedback de la client (client) cu privire la aspectul
vizual al aplicației.
Specificarea cerințelor interfeței
• Specificațiile interfeței includ detalii despre ceea ce este necesar
pentru ca actorul să interacționeze cu sistemul: nume, titlu și câteva
informații descriptive despre modul în care interfața este utilizată de
actor.
• Astfel, un document cu specificații de interfață include:
• Obiectivele actorului în interacțiunea cu sistemul (documentate și în
cazurile de utilizare),
• Lista interfețelor (bazate pe varietatea și numărul de interacțiuni pe care
un actor le va avea cu sistemul) și
• Navigare și dependențe (bazate pe fluxurile de proces documentate în
cazuri de utilizare, dar acum revizuite pe baza interfețelor).
• Standardul UML joacă un rol minim în modelarea unei UI. Nu există o
diagramă UML care să modeleze o interfață.
• UI-urile pot fi specificate folosind șabloane
Șablonul de specificații a interfeței
• Identificator interfață
< Acesta reprezintă numărul și denumirea interfeței>
• Actori
< O listă a actorilor care interacționează cu sistemul prin
această interfață>
• Cazuri de utilizare
< Lista cazurilor de utilizare în care apare această interfață>
• Scurtă descriere
< Descrierea în cateva rânduri a interfeței>
 Proiectarea interfețelor

• Primul pas - investigarea așteptărilor actorilor

referitor la interfață prin completarea chestionarelor
specifice constând din următoarele întrebări:
• Ce nivel de pregătire (informatică) trebuie să aibă actorul pentru
a realiza o anumită funcționalitate?
• Are actorul experiență de lucru în medii bazate pe ferestre?
• Are actorul experiență în utilizarea altor sisteme automate de
modelare a proceselor?
• Este necesar să consulte documente / cataloage în paralel cu
utilizarea aplicației?
• Actorul dorește să implementeze facilități de „salvare /
restaurare”?
Proiectarea interfețelor

• Obiectivele prototipului sunt:

• Stabilirea cerințelor interfeței pentru funcționalitățile
cheie ale aplicației;
• Acesta demonstrează clientului (într-o formă
vizuală) că cerințele proiectului au fost bine înțelese
și pot fi realizate;
• Începerea fazei de dezvoltare a elementelor
standard ale interfeței.
Detalii pentru proiectarea interfeței

• Fiecare interfață are datele sale descrise ca atribute în cadrul claselor /

programelor care manipulează și afișează aceste date. Aceste interfețe
sunt proiectate și dezvoltate iterativ. De exemplu, o schiță inițială în prima
iterație, nu oferă detalii specifice de proiectare, cum ar fi culoarea,
dimensiunea căsuțelor de text și așa mai departe.
 Proiectarea interfețelor

• Hărți cu structura ecranului (diagrame) sunt utilizate pentru

a descrie fluxul aplicației urmând principalele moduri de
utilizare.
• Reprezentare:
• Forme pătrate pentru reprezentarea ferestrelor modale (necesită
un răspuns al utilizatorului pentru a continua o activitate).
• Forme pătrate cu colțuri rotunjite pentru reprezentarea ferestrelor
nemodale
• Direcția de trecere arată calea de navigare a ferestrei.
Specificarea fluxului de interfețe utilizator -
harta de navigare pentru un doctor
• Diagramele de flux UI, numite ocazional și storyboard-uri, diagrame de
navigare a ecranului sau hărți de navigare, modelează relațiile și
dependențele dintre interfețele utilizator. Deoarece UML oferă o diagramă
de activități ca diagramă de flux, putem crea această hartă de navigare.
Ecranele sunt reprezentate de obiecte în această diagramă de activitate.
Ferestre care conţin tab-uri

Diagramă de structură a
ecranului
Proiectarea interfețelor pentru aplicații mobile
cu machete

Legenda descriind
scopul principal al
ecranului
Backround:
conectivitate și
informații adiacente

Legenda descriind Legenda descriind

scopul principal al ecranul secundar
ecranului

Separator al
Identificarea funcționalităților din
utilizatorului ecran

Functionalități
personalizate
pentru tuilizator

Functionalități cheie
personalizate pentru
utilizator
Proiectarea interfețelor pentru aplicații mobile
cu storyboard-uri

Formular
afisat cu
detalii ale
Daca butonul cerere
‘Cerere grup nou’ Buton afisat
este selectat pt
confirmare
/respingere

Se afișeaza
Este grupurile de
Antrenor antrenori.
selectată
Avem butoane Daca
Meniu opțiunea pt adaugarea
Logare ‘Adaugă
’Grupuri’ unui nou grup
principal grup’
și dc a fost
este
facută de client
o cerere pt selectat
grup nou Formular
afisat pt
adaugare
detalii grup
nou dorit de
antrenor
Considerații privind designul interfeței cu
utilizatorul

• Analistul de afaceri este inițial responsabil pentru specificațiile UI.

Aceste specificații sunt analizate în timpul proiectării UI pentru a
crea clase de interfață detaliate și implementabile.
• GUI-urile rezultate pot fi apoi organizate în funcție de actorii
(utilizatorii) care le vor folosi.
• GUI-urile sunt de obicei derivate din suportul grafic existent oferit
de mediul de dezvoltare: ferestre, bare de defilare și butoane radio
etc. Un obiect de tip FORM este de obicei disponibil și oferă cele
mai multe funcționalități GUI.
• Interfețele pot fi, de asemenea, create și reutilizate de către
designeri: o clasă de interfață comună este creată care reprezintă
fereastra principală pentru interacțiunea actorilor. Apoi, restul
interfețelor necesare acelui actor pot moșteni funcționalitatea
comună oferită de clasa de interfață comună
Treisprezece principii pentru proiectarea
modului de afișare
• Christopher Wickens și colab. au definit 13 principii ale
designului în cartea lor An Introduction to Human
Factors Engineering (2004)
• pot fi utilizate pentru proiectarea eficientă a modului de
afișare.
BENEFICII POTENȚIALE
• o reducere a erorilor și a timpului de pregătire necesar,
• o creștere a eficienței,
• o creștere a satisfacției utilizatorilor
Sunt grupate în 4 categorii
 a. Principii bazate pe percepție
1. Faceți afișajele lizibile (sau audibile). Legibilitatea unui afișaj este critică și
necesară pentru proiectarea unui afișaj utilizabil.
2. Evitați limitele absolute ale judecății. Nu cereți utilizatorului să determine nivelul
unei variabile pe baza unei singure variabile senzoriale (de exemplu, culoare,
dimensiune, sunet).
3. Procesare de sus în jos (top-down). Semnalele sunt cel mai probabil percepute și
interpretate în conformitate cu ceea ce se așteaptă pe baza experienței
utilizatorului. Dacă un semnal este prezentat contrar așteptării utilizatorului, poate fi
necesară prezentarea mai multor dovezi fizice ale semnalului pentru a fi înțeles
corect.
4. Creșterea redundanței. Dacă un semnal este prezentat de mai multe ori, este
mai probabil să fie înțeles corect. Acest lucru se poate realiza prin prezentarea
semnalului în forme fizice alternative (de exemplu, culoare și formă, voce și
imprimare etc.), deoarece redundanța nu implică repetarea..
5. Asemănarea provoacă confuzie: Utilizați elemente distincte. Semnalele care par
a fi similare vor fi probabil confundate. Raportul de caracteristici similare la
caracteristici diferite face ca semnalele să fie similare. De exemplu, A423B9 este
mai asemănător cu A423B8 ​decât 92 este cu 93.
b. Principiile modelului mental

6. Principiul realismului pictural. Un afișaj ar trebui să arate ca

variabila pe care o reprezintă (de exemplu, temperatura ridicată pe
un termometru arătat ca un nivel vertical mai mare). Dacă există mai
multe elemente, ele pot fi configurate într-o manieră care ar arăta la
fel ca în mediul reprezentat.
7. Principiul piesei în mișcare. Elementele în mișcare ar trebui să se
deplaseze într-un model și o direcție compatibile cu modelul mental
al utilizatorului cu privire la modul în care se mișcă efectiv în sistem.
De exemplu, elementul care se mișcă pe un altimetru ar trebui să se
deplaseze în sus, odată cu creșterea altitudinii.
c. Principii bazate pe atenție
8. Minimizarea costului accesuilui la informații sau al interacțiunii. Atunci când
atenția utilizatorului este redirecționată de la o locație la alta pentru a accesa
informațiile necesare, există un cost asociat în timp sau efort. O interfață ar
trebui să reducă la minimum acest cost, permițând localizarea surselor frecvent
accesate în cea mai apropiată poziție posibilă. Cu toate acestea, nu trebuie
sacrificată lizibilitatea adecvată pentru a reduce acest cost.
9. Principiul compatibilității proximității. Atenție împărțită între două surse de
informații poate fi necesară pentru finalizarea unei sarcini. Aceste surse trebuie
să fie integrate mental și sunt definite pentru a avea o proximitate mentală
strânsă. Costurile de acces la informații ar trebui să fie scăzute, ceea ce poate fi
obținut în mai multe moduri (de exemplu, apropierea, creare unei legături prin
culori, modele, forme etc.). Cu toate acestea, apropierea excesivă a elementelor
de afișat poate fi dăunătoare provocând prea multă aglomerație.
10. Principiul resurselor multiple. Un utilizator poate prelucra mai ușor
informațiile prezentate prin diferite resurse. De exemplu, informațiile vizuale și
auditive pot fi prezentate simultan, în loc să fie prezinte exclusiv vizual sau
auditiv.
d. Principiile bazate pe memorie

11. Înlocuiți memoria cu informații vizuale: cunoștințe din lume. Un utilizator nu

trebuie să rețină informații importante doar în memoria de lucru sau să le
recupereze din memoria pe termen lung. Un meniu, o listă de verificare sau un
alt afișaj poate ajuta utilizatorul ușurând utilizarea memoriei sale. Utilizarea
cunoștințelor memorate de un utilizator și cunoștințele din lume trebuie să fie
echilibrate pentru un design eficient.
12. Principiul ajutorului predictiv. Acțiunile proactive sunt de obicei mai eficiente
decât acțiunile reactive. Un afișaj ar trebui să încerce să elimine sarcinile
cognitive care necesită resurse și să le înlocuiască cu sarcini perceptive mai
simple pentru a reduce utilizarea resurselor mentale ale utilizatorului. Acest
lucru va permite utilizatorului să se concentreze asupra condițiilor actuale și să
ia în considerare posibile condiții viitoare. Un exemplu de ajutor predictiv este un
indicativ rutier care afișează distanța până la o anumită destinație.
13. Principiul consecvenței. Obiceiurile vechi de la alte afișaje se transferă cu
ușurință pentru a sprijini procesarea de afișaje noi dacă sunt proiectate în mod
consistent. Memoria unui utilizator pe termen lung va declanșa acțiuni care se
așteaptă să fie adecvate. Un design trebuie să accepte acest fapt și să utilizeze
consecvență între diferite afișaje
Proiectarea bazei de date

• Se pleacă de la modelul claselor domeniului

• Se alege structura bazei de date
• De obicei se lucreaza cu baze de date relaționale, dar
pot există platforme care lucrează cu baze de date
orientate obiect sau alte sisteme NoSQL
• Se proiectează arhitectura BD (distribuită, etc)
• Se proiectează schema bazei de date
• Tabelele și coloanele în relațional
• Se proiectează restricțiile de integritate referențială
• Referințe prin chei externe
Stereotipuri pentru persistență

• Majoritatea obiectelor stereotipe <entity> trebuie să existe

chiar și după închiderea sistemului
• În timp ce un obiect persistent există dincolo de execuția
sistemului, un obiect tranzitoriu dispare atunci când sistemul
este oprit și este recreat atunci când sistemul este executat
din nou. Majoritatea obiectelor <control> și <boundary> sunt
tranzitorii și nu este necesară salvarea acestor tipuri de
obiecte.
Mecanismul persistenței - baze de date

• Persistența poate lua diverse forme. Mai jos prezentăm câteva

tehnici pentru a face obiectele persistente:
• Stocarea într-un fișier flat. O astfel de stocare poate conține datele
utilizate de sistem, dar nu este inteligentă și nu oferă o modalitate de
a căuta în date.
• Stocarea într-un fișier cu mecanism de acces secvențial indexat
sau într-o bază de date care organizează datele prin indexuri care
pot fi utilizate pentru căutarea înregistrărilor de date specifice și
actualizarea acestora.
• Stocarea într-o bază de date relațională, care este cea mai potrivită
pentru datele de afaceri care pot fi ușor formatate în rânduri și
coloane, fiind optimizate astfel pentru căutare.
• Stocarea într-o bază de date orientată obiect, care este mai
potrivite pentru informații științifice sau neformatate.
• Stocarea într-o bază de date NoSQL, care poate gestiona
documente mari, nestructurate și date care pot fi căutate în mod
opțional.
Baze de date orientate obiect

• BDOO sunt capabile să stocheze obiecte împreună cu

valorile atributelor acestora, operațiile și relațiile lor.
• Structurile obiectului din memorie în timpul execuției pot fi
stocate direct „as is” în baza de date. Obiecte binare de
dimensiuni mari (BLOB) și datele complexe nestructurate
(de exemplu, video și audio) pot fi de asemenea stocate în
aceste baze de date fără a fi nevoie de conversie
• De asemenea, stochează relații precum moștenirea,
asocierea și agregarea direct în baza de date.
Baze de date NoSQL

• Nu respectă formatul rând-coloană tradițional al unei baze de date

cu un limbaj de interogare structurat (SQL), (baza de date
relațională), dar este capabil să gestioneze date nestructurate.
• Tehnologia pe care se bazează permite gestionarea volumelor
mari de date.
• Bazele de date NoSQL gestionează o structură de baze de date
complicată și federalizată, care se regăsește de obicei în Cloud.
Structura bazei de date federalizată a bazelor de date NoSQL
este de asemenea înțeleasă ca o arhitectură de baze de date
distribuite
• De exemplu, o relație Client-Cont nu este doar o asociere; Cont
este o colecție de conturi care aparțin clientului și vor fi
încorporate în fiecare Client
Bazele de date relaționale

• Majoritatea aplicațiilor comerciale utilizează în continuare

baze de date relaționale. Acestea oferă mecanisme ideale și
mature pentru stocarea, preluarea și gestionarea datelor
structurate
• Tabelele sunt structural diferite de obiecte și necesită
„traducerea” claselor în tabele
• Cele mai multe instrumente de modelare bazate pe UML
permit arhitectului să marcheze clasele ca persistente, ele
pot fi apoi folosite de instrumente pentru a crea o schemă
inițială a bazei de date relaționale pe baza diagramelor de
clase.
 Maparea obiectelor domeniului pentru SGBDR
1. Maparea tuturor claselor concrete ale domeniului în tabele. De asemenea dacă o clasă
abstractă a domeniului are moștenitori direcți multiplii, mapăm clasa într-o tabelă.
2. Mapăm atributele cu valoare unică în coloane ale tabelei
3. Mapăm metodele în proceduri stocate sau module de program
4. Mapăm agregările și relațiile de asociere cu multiplicitate unu-la-unu într-o coloană care poate
stoca cheia tabelei asociate ex: adăugăm o cheie externă tabelei. Facem acest lucru pentru
ambele capete ale relației.
5. Mapăm atributele multi-valoare și grupurile repetitive în tabele noi și creăm asocierei 1-n de la
tabela originală către cele noi.
6. Mapăm agregările și relațiile de asociere cu multiplicitate mulți-la-mulți într-o nouă tabelă de
legătură între cele 2 tabele originale. Copiem cheile primare din ambele tabele în noua tabelă.
7. Pentru relații de agregare și asociere de tip mixt, copiem cheia primară din partea 1 a relației
(1..1 sau 0..1) într-o nouă coloană în tabela aferentă laturii mulți (1..* sau 0..*) a relației care
poate stoca cheia tabelei de legătură ex: adăugăm p cheie externă tabelei de pe latura multi a
relației.
8a. Ne asigurăm că cheia primară a subclasei este aceeași ca și cheia primară a superclasei.
Multiplicitatea acestei noi asocieri de la subclasă la superclasă ar trebui sa fie 1..1. Dacă
superclasele pot fi instanșiate, atunci multiplicitatea dinspre superclasă către subclasă este 0..1,
altfel este 1..1. Mai mult, o restricție exclusivă (XOR) trebuie să fie adăugată între asocieri.
Facem acest lucru pentru fiecare superclasă
SAU
8b. Aplatizăm ierarhia de moștenire prin copierea atributelor superclasei în toate subclasele și
eliminarea superclasei din model.
 Relațiile de moștenire și tabele relaționale

Care sunt
modurile
posibile de a
mapa Pacient și
Doctor?
• O singură
tabelă
• 2 tabele, una
pt Pacient,
alta pt Doctor
• 3 tabele?
Relațiile de moștenire

a) Cel mai simplu mod este să mapăm toate atributele din

clasa părinte, precum și subclase, pe coloanele unui
singure tabele. Spațiu irosit: când un obiect Pacient este
stocat în acest tabel anume, acesta ar lăsa coloanele
specifice Doctorului necompletate.
b) Creați tabele pentru toate clasele pentru copii și adăugați-i
atributele clasei părinte. Această abordare devine mai
dificilă pentru mai multe niveluri de moștenire.
c) Creați tabele separate atât pentru clasa părinte, cât și
pentru copii. Aceste tabele sunt apoi legate cu ajutorul
cheii primare a tabelei care reprezintă clasa părinte
(PersonID)
Multiplicități și clase de asociere

• Fiecare clasă este transformată inițial într-o tabelă în baza de date

relațională și o nouă tabelă este creată pentru a mapa asocierea;
multiplicități mulți-la-mulți nu pot fi implementate direct.
Multiplicități și clase de asociere

• Maparea unei clase de asociere variază în diferite cazuri și depinde de

multiplicități.
• Maparea va rezulta în două tabele, cu cheia pentru Doctor adăugată
tabelei de stocare a pacienților. Cu toate acestea, clasa de asociere nu
este mapată într-o tabelă. În schimb, atributele data / ora sunt anexate
tabelei Pacient
Maparea agregărilor
• Ambele clase vor fi mapate în tabele individuale. Cheia clasei de asociere va fi anexată
tabelei corespunzătoare: PrescriptionLine va conține PresID, cheia tabelei
Prescription.
• Ori de câte ori un obiect Prescription este distrus, trebuie să aveți grijă să eliminați
toate obiectele PrescriptionLine înrudite.
 ➢ Diagrama de
Diagramele de componente
implementare ➢ Diagrama de
desfășurare
Diagrama de componente
 O diagramă de componente prezintă dependenţele
existente între diverse componente software ce compun
un sistem informatic.
 Aceste dependențe sunt:
➢ statice - au loc in etapele de compilare sau link-editare
➢ dinamice - au loc in timpul execuţiei
 Modelează arhitectura de ansamblu și componentele
locale din interiorul acesteia.
 Componente ale sistemului, logice și reutilizabile, care
definesc arhitectura sistemului.
 Interfețe bine definite sau metode publice, care pot fi
accesate de alte programe sau dispozitive externe.
Componenta
 O componentă este un modul sau program executabil (cod
sursă, cod binar, dll, executabil, script etc) și constă din toate
clasele care sunt compilate într-o singură entitate.
 Fiecare componentă este responsabilă pentru un obiectiv clar
în cadrul întregului sistem și interacționează numai cu alte
elemente esențiale, în funcție de necesitate.
 La un nivel înalt de abstractizare, componentele sunt
considerate unități autonome încapsulate într-un sistem sau
subsistem care furnizează una sau mai multe interfețe. Prin
clasificarea unui grup de clase ca și componentă, întregul
sistem devine mai modular, deoarece componentele pot fi
schimbate și reutilizate.
 O componentă este trasată ca un dreptunghi cu compartimente
opționale organizate vertical.
 Stereotipuri pentru componente
▪ Exemple de stereotipuri predefinite pentru componente:
▪ <<buildComponent>>
▪ <<document>>
▪ <<executable>>
▪ <<file>>
▪ <<library>>
▪ <<entity>>
▪ <<service>>
Interfața
• Interfața specifică un contract constând dintr-un set
de atribute și operații publice pentru o clasă.
• Exista doua tipuri de interfețe ale componentelor:
• Furnizată - oferite de către componetă, se reprezintă cu
simbolul unui cerc.
• Solicitată – necesare interfeței, se reprezintă cu un
semicerc.
Portul
• Porturile sunt reprezentate folosind un pătrat de-a lungul
marginii unei componente.
• Un port este adesea folosit pentru a ajuta la expunerea
interfețelor necesare și furnizate ale unei componente.
• Este o fereastră explicită într-o componentă încapsulată. Toate
interacțiunile în și din astfel de componente trec prin porturi.
• Fiecare port furnizează sau necesită una sau mai multe
interfețe specifice
Relații frecvent utilizate în diagrama de componente
• Dependență
• linie întreruptă îndreptată spre furnizorul
componentei
• clasele incluse în componenta client pot moșteni,
instanția sau utiliza clasele incluse în componenta
furnizorului
• pot fi, de asemenea, relații de dependență între
componente și interfețe ale altor componente
• Relația de compunere (componente incluse fizic
în alte componente).
Modelarea codului sursă
• Prin inginerie directă sau inversă, identificați setul de fișiere de cod
sursă necesare și modelați-le ca și componente cu sterotipul <<file>>.
• Pentru sisteme mai mari, utilizați pachete pentru a afișa grupuri de
fișiere de cod sursă.
• Luați în considerare descrierea unei valori etichetate care să indice
informații precum numărul versiunii fișierului cod sursă, autorul
acestuia și data ultimei modificări.
• Modelați dependențele de compilare dintre aceste fișiere folosind
dependențe.
Modelarea unei distribuții executabile
• Identificați setul de componente pe care doriți să le modelați. Se pot identifica
toate componentele prezente într-un singur nod sau distribuirea acestor seturi
de componente pe toate nodurile din sistem.
• Specificați stereotipul fiecărei componente din acest set. Pentru majoritatea
sistemelor, va fi identificat un număr redus de tipuri de componente (cum ar fi
executabile, biblioteci, tabele, fișiere și documente).
• Pentru fiecare componentă din acest set, luați în considerare relația sa cu vecinii
săi. Cel mai adesea, aceasta va implica interfețe care sunt exportate (realizate)
de anumite componente și apoi importate (utilizate) de către altele. Dacă se
dorește un model cu un nivel mai ridicat de abstractizare, se pot elimina
interfețele, arătând numai dependențe dintre componente.
Interdependențe și pachete
Exemplu 1
Exemplu 2
Diagrama de desfăşurare
• Diagramele de desfășurare sunt utilizate pentru a
reprezenta relațiile dintre componentele hardware
utilizate în infrastructura fizică a unui sistem informatic.
• De exemplu, atunci când este proiectat un sistem
informatic distribuit care va utiliza o rețea pe o zonă
extinsă, o diagramă de desfășurare poate să fie folosită
pentru a arăta relațiile de comunicare dintre diferitele
noduri din rețea.
• De asemenea, acestea pot fi folosite pentru a reprezenta
componentele software și modul în care acestea sunt
alocate peste arhitectura fizică sau infrastructura unui
sistem informatic. În acest caz, o diagramă de desfășurare
reprezintă mediul necesare pentru execuția
componentelor software.
Diagrama de desfăşurare
• Elementele de bază ale unei diagrame de desfășurare
sunt nodurile, artefactele și căile de comunicare.
• Un nod reprezintă orice element hardware care
trebuie inclus în modelul de proiectare a unei
arhitecturi fizică. De exemplu, nodurile pot include
computere client, servere, rețele separate sau
dispozitive de rețea individuale.
• În mod obișnuit, un nod este etichetat cu ajutorul lui
numele și, eventual, cu un stereotip. Stereotipul este
modelat ca element de text înconjurat de simbolurile "<<
>>". Stereotipul reprezintă tipul de nod reprezentat în
diagramă.
• Exemple tipice de dispozitive: dispozitivul mobil, serverul
de baze de date, serverul Web și serverul de aplicații.
Diagrama de desfăşurare
• Un artefact reprezintă o piesă a sistemului informatic
care urmează să fie implementată pe arhitectura
fizică. În mod obișnuit, un artefact reprezintă o
componentă software, un subsistem, o tabelă dintr-o
baze de date, o întreagă bază de date sau un nivel al
aplicației (gestionarea datelor sau interacțiunea om-
calculator). Artefactele pot fi etichetate atât cu un
nume, cât și cu un stereotip.
• O cale de comunicare reprezintă o legătură între
nodurile arhitecturii fizice. Căile de comunicare sunt
stereotipizate pe baza tipului de legături pe care le
reprezintă (de exemplu, LAN, Internet, serial, paralel
sau USB) sau un protocol (de exemplu, TCP / IP).
 Diagrama de desfăşurare – notații
Element Reprezentare
Nodul:
▪ Este o resursă de calcul, de exemplu un computer client, un server,
o rețea separată sau un dispozitiv de rețea individuală.
▪ Este etichetat cu numele său.
▪ Poate conține un stereotip pentru a eticheta în mod specific tipul
de nod reprezentat, de exemplu, dispozitiv, stație de lucru client,
server de aplicații, dispozitiv mobil etc.
Artefactul:
▪ Este o specificare a unei componente software.
▪ Este etichetat cu numele său.
▪ Poate conține un stereotip pentru a marca în mod specific tipul de
artefact (fișierul sursă, tabelă de baze de date, fișier executabil).

Calea de comunicare:
▪ Reprezintă o asociere între două noduri.
▪ Permite nodurilor să schimbe mesaje.
▪ Poate conține un stereotip pentru a eticheta în mod specific tipul
de cale de comunicare reprezentat (Internet, serial, paralel) sau
poate fi doar denumită sau poate fi calificată (agregare,
compunere, dependență, generalizare etc.)
 Diagrama de desfăşurare
• Diagramele de desfăşurare conţin două tipuri de noduri:
dispozitive și mediile de execuţie.
➢Dispozitivele (Device) sunt resurse de calcul cu capacități de
procesare și capacitatea de a executa programe (calculatoare,
laptopuri și telefoane mobile).
➢Mediile de execuţie (EEN – Execution Environment Node) sunt
noduri care conțin medii software capabile să execută alte
entități software precum sisteme de operare, servere web
(Apache sau Microsoft's Internet Information Server (IIS) sau
Java Runtime Environment (JRE)).
 Diagrama de desfăşurare
• Diagramele de desfăşurare pot fi utilizate pentru
reprezentarea componentelor ce pot aparţine anumitor
noduri prin imbricarea grafică a simbolului componentei
în cadrul simbolului ce reprezintă nodul.
Diagrama de desfăşurare - exemplu
 ACADEMIA DE STUDII ECONOMICE BUCUREŞTI
FACULTATEA DE CIBERNETICĂ, STATISTICĂ ŞI INFORMATICĂ ECONOMICĂ

P RO I E C TA R E A S I S T E M E LO R
I N F O R M AT I C E

-CURS 10-

BUCUREȘTI
2020-2021
Metodologii de
realizare a
sistemelor
informatice
METODOLOGII DE REALIZARE A
SISTEMELOR INFORMATICE
• O metodologie reprezintă o abordare formalizată a implementării ciclului
de viață. Scopul acesteia este să ofere indicații privind modul de
dezvoltare a sistemului, furnizând, o listă de pași care trebuie urmați și de
livrabile corespunzătoare acestora.
• Există o mare varietate de metodologii de dezvoltare a sistemelor și
fiecare este unică, în funcție de ordonarea etapelor de dezvoltare și de
importanța pe care o acordă fiecăreia dintre ele.
• Unele metodologii sunt standarde formale utilizate de agențiile
guvernamentale, în timp ce altele au fost dezvoltate de companii de profil
pentru a le oferi clienților.
• Multe organizații au metodologii interne care au fost perfecționate de-a
lungul anilor.
• Metodologiile pot fi clasificate după diferite criterii.
TIPOLOGIA METODOLOGIILOR DE
REALIZARE A SISTEMELOR INFORMATICE
A. Clasificare după gradul de generalitate:
• Metodologiile generale au un grad înalt de generalitate, pot fi folosite
pentru realizarea sistemelor informatice din domenii diferite. Exemple:
SSADM (Structured System Analysis and Design Methodology),
MERISE (Méthode d’Etude et de Realization, Informatique pour les
Systèmes d’Entreprise), OMT (Object Modeling Technique), RUP
(Rational Unified Process).

• Metodologii specializate sunt cele dezvoltate şi utilizate pentru

implementare a unui singur produs software. Exemplu: ASAP (pentru
SAP).
TIPOLOGIA METODOLOGIILOR DE
REALIZARE A SISTEMELOR INFORMATICE
B. Clasificare din punct de vedere al modului de abordare al
sistemelor:
• Metodologiile cu abordare structurată au ca principiu de lucru
împărțirea sistemului în subsisteme pe baza funcțiilor sistemului
(abordarea funcțională) sau în funcție de date (abordarea bazată pe
date). Propun modelarea datelor separat de modelarea procedurilor.
Modelarea procedurilor se face plecând de la ideea că funcțiile sunt
active, având un comportament, iar datele sunt afectate de aceste funcții.
• Metodologiile cu abordare orientată obiect permit construirea sistemelor
informatice folosind conceptele tehnologiei orientate obiect. Tehnologia
orientată obiect a apărut odată cu apariția limbajelor de programare
orientate obiect (SIMULA (1960), SMALLTALK (1970), EIFFEL, C++,
Object Pascal (1980)).
METODOLOGII CU ABORDARE
STRUCTURATĂ
• Utilizează reprezentării grafice, la îndemâna atât a
analiștilor, cât și a beneficiarilor.
• Permite lanificarea eficace a proiectului prin divizarea
în subsisteme.
• Oferă posibilitatea reducerii timpului și a costului de
dezvoltare a sistemului prin luarea în considerare de la
început a detaliilor, prin interacțiunea continuă cu
beneficiarul.
• Folosesc diferite tehnici pentru reprezentarea
sistemului:
– Diagrame de flux de date
– Diagrame entitate-relație
– Diagrame de tranziție a stărilor
– Dicționar de date
– Arbori decizionali
– Tabele de decizie
– Engleza structurată
– Pseudocod
METODOLOGII CU ABORDARE
ORIENTATĂ OBIECT
• Datele și prelucrările nu sunt reprezentate distinct, ca
în cazul abordării structurate, ci încapsulat în clase de
obiecte.
• Modelul realizat pentru un sistem poate fi modificat în
scurt timp pentru a fi utilizat pentru modelarea sistemelor
din aceeași sferă de activitate.
• Oferă consistență crescută între activitățile de analiză,
proiectare și programare.
• Sunt orientate pe structura și comportamentul
obiectelor care compun sistemul.
• Procesul de dezvoltare este iterativ și incremental,
permițând rafinarea și extinderea modelelor.
• Permit modelarea arhitecturii logice și fizice a
sistemului.
• Folosesc o multitudine de diagrame pentru
reprezentarea grafică a aspectelor statice, dinamice și
funcționale ale sistemului (spre exemplu, limbajul UML
oferă 14 tipuri de diagrame).
TIPOLOGIA METODOLOGIILOR DE
REALIZARE A SISTEMELOR INFORMATICE
C. Clasificare după modelul de parcurgere a etapelor ciclului de viață:
• Modelul de parcurgere în cascadă

• Modelul de parcurgere în spirală

• Modelul de parcurgere cu extensii

• Modelul de parcurgere evolutiv

• Bazate de dezvoltarea rapidă (RAD)

• Bazate pe dezvoltarea agilă

MODELUL DE PARCURGERE ÎN CASCADĂ
✓ Parcurgerea secvențială a etapelor, cu eventuale reveniri la etapa
precedentă.
✓ Utilizat pentru sisteme informatice de mică complexitate.
✓ Modelul în cascadă sau liniar este teoretic, deoarece în realitate,
parcurgerea etapelor este un proces iterativ, desfășurându-se adesea în
paralel mai multe activități.

Planificare

Analiza

Proiectarea

Implementarea

Testarea

Utilizarea şi
întreţinerea
MODELUL DE PARCURGERE ÎN
SPIRALĂ (MODELUL CU PROTOTIP)
✓ Presupune elaborarea completă, rapidă şi la costuri scăzute a unei
versiuni iniţiale, simplificate, cu caracter de prototip, pe baza căreia
se stabilesc noi specificaţii de definire a sistemului informatic şi se
desfăşoară activitatea de realizare a unei noi versiuni de sistem
informatic.
✓ Elaborarea noii versiuni presupune parcurgerea integrală sau parţială
a etapelor, modificându-se numai anumite părţi din prototip.
Prototip 4

Prototip 3

Prototip 2

Prototip 1
 MODELUL DE PARCURGERE CU
EXTENSII (INCREMENTAL) Planificare

✓ Se utilizează atunci când sistemele

informatice se pot realiza şi pune în Analiză
funcţiune parţial pe subsisteme,
aplicaţii, module.
Proiectare Proiectare
✓ Realizarea lor se poate face deci în subsistem 1 subsistem n

maniera extensibilă, astfel încât la

început se analizează şi se definesc Implementare Implementare
cerinţele, iar apoi subsistemele se subsistem 1 subsistem n

realizează şi se integrează prin extensii ………………………

…
succesive sau simultane. Testare Testare
subsistem 1 subsistem n

✓ De obicei, extensiile se ramifică din

etapa de proiectare a sistemului
Întreţinere Întreţinere
informatic. subsistem 1 subsistem n
MODELUL DE PARCURGERE EVOLUTIV
✓ Se utilizează în cazul sistemelor complexe, care se descompun în
subsisteme. Ele sunt realizate şi livrate în mod iterativ şi contribuie la
sporirea treptată a performanţelor sistemului.
✓ Pornește de la un studiu inițial privind obiectivele sistemului informatic.
✓ Ulterior, oricare dintre subsisteme trece prin toate fazele de dezvoltare a
sistemelor: definirea cerinţelor, analiză, proiectare, implementare, testare,
intreţinere, pentru ca în final acestea să fie integrate.
✓ Este rezultatul unei concepții bazate pe arhitecturi deschide și flexibile.
METODOLOGIA UNIFICATA DE REALIZARE A
SISTEMELOR INFORMATICE (RUP)

• Rational Unified Process (RUP) este un proces general pentru dezvoltarea

orientată obiect de produse informatice.
• Este un ghid care arată cum se poate utiliza practic UML (Unified Modeling
Language) pentru a dezvolta un sistem informatic.
• RUP a fost realizat de compania Rational şi dezvoltat acum de către IMB.
• Nucleul îl reprezintă metodologia propusă de Jacobson, Booch şi Rumbaugh
(Unified Process) care este mai mult decât un simplu proces, este un cadru
general care a permis dezvoltarea de metodologii specializate (pe diverse
tipuri de sisteme informatice în funcţie de aria de aplicare, diverse tipuri de
organizaţii, niveluri de competenţă sau dimensiuni diferite ale proiectelor)
FAZELE RUP

Axa orizontală: reprezintă

timpul şi evidenţiază
aspectele dinamice ale
procesului. Pe axa orizontală
procesul se exprimă în
termeni de: cicluri, faze,
iteraţii şi jaloane.

Axa verticală: reprezintă

aspectele statice ale
procesului şi se exprimă în
termeni de: activităţi,
produse, executanţi şi fluxuri.
Figura X.1: Fazele şi fluxurile Procesului unificat de dezvoltare software
METODOLOGII BAZATE PE DEZVOLTAREA RAPIDĂ
RAD (RAPID APPLICATION DEVELOPMENT)

• Se referă la o serie de principii care urmăresc ajustarea etapelor de realizare a

sistemelor informatice, astfel încât o parte a sistemului să fie dezvoltată și să ajungă
la utilizatori rapid.
• Astfel, utilizatorii pot înțelege mai bine sistemul și pot sugera revizuiri care aduc
sistemul mai aproape de cerinţele acestuia.
• Se recomandă ca analiștii să folosească tehnici speciale și instrumente informatice
pentru a accelera etapele de analiză, proiectare și implementare, cum ar fi:
• instrumente CASE;
• sesiuni comune pentru stabilirea cerinţelor Join Requirement Planning (JRP);
• limbaje de programare de generația a patra;
• limbaje de programare vizuale ;
• generatoare de cod;
• reutilizarea componentelor software;
• Astăzi, aproape toate mediile de dezvoltare integrate au facilităţi specifice RAD.
METODOLOGII BAZATE PE DEZVOLTAREA RAPIDĂ
RAD (RAPID APPLICATION DEVELOPMENT)
▪ RAD comprimă paşii metodologiilor tradiţionale într-un proces iterativ.
▪ Se bazează pe prototipizare şi pe revizuiri ale utilizatorilor înainte de a trece la
parcurgerea unei noi iteraţii.

Metodologii tradiţionale

Planificare Analiză Proiectare Implementare Testare Utilizare

RAD
Documentarea
Proiectare
cerinţelor

Sesiuni pentru Iterativ Implementare

stabilirea cerinţelor

Revizuiri ale
utilizatorilor Testare
METODOLOGII BAZATE PE DEZVOLTAREA AGILĂ

• Aceste metodologii sunt orientate pe programare şi au puține reguli și practici.

• Toate metodologiile de dezvoltare agile sunt bazate pe manifestul agil și pe un
set de douăsprezece principii:
• Este prioritară satisfacţia clientului prin livrarea rapidă şi continuă de software
calitativ.
• Schimbarea cerinţelor este binevenită chiar şi într-o fază avansată a dezvoltării.
Procesele agile valorifică schimbarea în avantajul competitiv al clientului.
• Livrarea de software funcţional se face frecvent, de preferinţă la intervale de timp
cât mai mici, de la câteva săptămâni la câteva luni.
• Oamenii de afaceri şi dezvoltatorii trebuie să colaboreze zilnic pe parcursul
proiectului.
• Proiecte se construiresc în jurul oamenilor motivaţi. Oferindu-le mediul propice şi
suportul necesar este foarte probabil că obiectivele vor fi atinse.
METODOLOGII BAZATE PE DEZVOLTAREA AGILĂ

• Principii ale manifestulului agil- continuare:

• Cea mai eficientă metodă de a transmite informaţii înspre şi în interiorul echipei de
dezvoltare este comunicarea faţă în faţă.
• Software-ul funcţional este principala măsură a progresului.
• Procesele agile promovează dezvoltarea durabilă. Beneficiarii, dezvoltatorii şi
utilizatorii trebuie să poată menţine un ritm de lucru constant pe termen lung.
• Atenţia continuă pentru excelenţă tehnică şi design bun îmbunătăţeşte agilitatea.
• Simplitatea-arta de a maximiza cantitatea de muncă nerealizată- este esenţială.
• Cele mai bune arhitecturi, cerinţe şi design sunt create de echipe care se auto-
organizează.
• La intervale regulate, echipa reflectă la cum să devină mai eficientă, apoi îşi
adaptează şi ajustează comportamentul în consecinţă.
METODOLOGII BAZATE PE DEZVOLTAREA AGILĂ

• Pe baza acestor principii, metodologiile agile se concentrează pe optimizarea

procesului de dezvoltare a sistemelor prin eliminarea unei părți semnificative din
modelare și documentare.
• Este susținută realizarea simplă, iterativă a sistemelor. Practic toate metodologiile
agile sunt folosite în combinație cu tehnologiile orientate-obiect.
• Toate metodologiile bazate pe dezvoltarea agilă urmează un ciclu de dezvoltare
simplu prin parcurgerea etapelor tradiționale ale procesului de dezvoltare a
sistemelor.
• Două dintre cele mai populare exemple de metodologii de dezvoltare agile sunt Extreme
Programming (XP) și SCRUM.

Planificare Planificare Planificare

Analiză Analiză Analiză
Proiectare Proiectare Proiectare
Implementare Implementare Implementare
Iteraţia 1 Iteraţia 2 Iteraţia 3...

Sistem
Sistem
Sistem
METODOLOGII BAZATE PE DEZVOLTAREA AGILĂ

Avantaje Dezavantaje

Abordare realistă în realizarea sistemelor Nu sunt potrivite pentru a gestiona

informatice. dependenţe complexe.
Promovează lucrul în echipă şi învăţarea. Risc crescut de sustenabilitate,
mentenabilitate și extensibilitate.
Funcţionalităţile pot fi implementate rapid şi Fără o documentație suficientă, nici sistemul
verificate. şi nici procesul de dezvoltare al sistemelor nu
pot fi auditate.
Model potrivit pentru mediile care se schimbă Depinde foarte mult de interacţiunea cu
în mod continuu. beneficiarul.
Reguli minime, documentaţie uşor de realizat. Transferul de informaţii către membrii noi ai
echipei este îngreunat de lipsa documentaţiei.
Uşor de gestionat. Lipsa regulilor poate duce la apariţia unui
mediu de lucru haotic.
Oferă flexibilitate. Dependenţa de membrii echipei care cunosc
cerinţele sistemului.
EXTREME PROGRAMMING - XP
• Pune accentul pe codificare (standarde, principii) - utilizează un set comun de
nume, descrieri și practici de codificare.
• Susţine ca programatorii să lucreze câte doi (“pair programming”), iar
programatorii au o responsabilitate comună pentru fiecare componentă software
elaborată.
• Numeroase sesiuni de discuţii pe parcursul dezvoltării.
• Feedback rapid al utilizatorilor finali în mod continuu.
• Dezvoltatorii trebuie să aibă o mentalitate orientată către calitate.
• Se bazează foarte mult pe refactoring, care este un mod disciplinat de
restructurare a codului pentru a-l păstra simplu.
• Sistemul este dezvoltat într-un mod evolutiv și incremental.
• Fiecare iteraţie (1-4 săptămâni) are un rezultat funcţional.
• Suport redus pentru modelare.
• Relaţie strânsă între clienţi şi dezvoltatori.
• Lipsa documentaţiei de realizare.
EXTREME PROGRAMMING - XP

Când se recomandă:
• Pentru proiectele mici cu echipe extrem de motivate, unite, stabile, și cu
experiență, XP ar trebui să funcționeze foarte bine.
• XP este recomandat numai pentru grupuri mici de dezvoltatori, nu mai mult
de zece persoane.
• Pentru cicluri scurte de dezvoltare şi atunci când sunt facilitate dicuţiile
frecvente cu utilizatorii finali.
Când NU se recomandă:
• În cazul în care proiectul nu este mic sau echipele nu sunt unite, succesul unui
efort de dezvoltare XP este îndoielnic.
• Există dubii asupra beneficiilor introducerii unor contractori externi în cadrul
unei echipe existente, când se lucrează conform XP.
• XP necesită un grad ridicat de disciplină; în caz contrar proiectele vor deveni
nefocalizate și haotice.
• Nu se recomandă pentru aplicații mari. Din cauza lipsei de analiză și
documentației de proiectare, există doar documentație cod asociat cu XP, deci
menținerea sistemelor de mari dimensiuni construite cu XP poate fi
imposibilă.
 SCRUM

• Numele metodologiei este preluat din jocul de rugby, şi desemnează o

grămadă ordonată folosită pentru a reporni un joc
• Creatorii metodei Scrum cred că indiferent cât bine este realizată
planificarea dezvoltării unui sistem, de îndată ce software-ul începe să
fie dezvoltat va izbucni haosul și planurile nu vor mai avea utilitate.

Principii de organizare
• Echipele sunt auto-organizate și auto-dirijate.
• Spre deosebire de alte abordări, echipele Scrum nu au un lider de
echipă desemnat.
• Echipele se organizeze într-o manieră simbiotică și își stabileasc
propriile obiective pentru fiecare sprint (iterație).
 SCRUM

Principii de funcţionare
• Odată ce un sprint a început, echipele Scrum nu mai iau în
considerare nici o cerință suplimentară.
• Orice cerințe noi care sunt descoperite sunt plasate într-o listă de
cerințe care urmează să fie abordate.
• La începutul fiecărui zile de lucru, are loc o reuniune unde toți
membrii echipei stau într-un cerc și raportează realizările zilei
precedente, stabilesc ce au de gând să facă astăzi și descriu tot ceea ce
a blocat progresul în ziua precedentă.
• Pentru a asigura un progres continuu, orice blocaj identificat este
abordat în următoarea oră.
• La sfârșitul fiecărui sprint, echipa prezintă software-ul clientului.
• Pe baza rezultatelor iterației încheiate, este început un nou plan
pentru următoarea iterație.
Proiectarea sistemelor
informatice
Seminar 10 - Limbajul UML
❑ Diagrama de componente
❑ Diagrama de desfășurare
 O diagramă de componente prezintă dependenţele existente între
diverse componente software ce compun un sistem informatic.

Diagrama de Aceste dependențe pot fi: a) statice - au loc in etapele de compilare

sau link-editare; b) dinamice - au loc in timpul execuţiei.
componente
Modelează arhitectura de ansamblu și componentele locale din
interiorul acesteia, identificând:

Componente ale sistemului, logice și reutilizabile, care definesc

arhitectura sistemului.

Interfețe bine definite sau metode publice, care pot fi

accesate de alte programe sau dispozitive externe.
Componenta
• Este un fișier, modul software sau program executabil (cod sursa, cod binar, dll,
executabil etc) cu o interfaţă bine definită.
• O componentă este responsabilă pentru un obiectiv clar în cadrul întregului sistem și
interacționează numai cu alte elemente esențiale, în funcție de necesitate.
• La un nivel înalt de abstractizare, componentele sunt considerate unități autonome
încapsulate într-un sistem sau subsistem care furnizează una sau mai multe interfețe.
• Clasificând un grup de clase ca și componentă, sistemul devine mai modular.
Componentele pot fi schimbate și reutilizate.
• O componentă este reprezentată ca un dreptunghi având compartimente opționale
organizate vertical.
• Se poate defini și folosind stereotipul <<component>>.
Stereotipuri pentru componente
• Stereotipurile au rolul de a preciza tipul de componentă software. Se poate
alege dintre sterotipurile predefinite sau se pot adăuga stereotipuri noi.
• Exemple de stereotipuri predefinite pentru componente:
▪ <<buildComponent>>
▪ <<document>>
▪ <<executable>>
▪ <<file>>
▪ <<library>>
▪ <<entity>>
▪ <<service>>
Interfața
• Interfața specifică un contract constând dintr-un set de atribute și operații publice
pentru o clasă.
• Există două tipuri de interfețe ale componentelor:
• Furnizată - oferită de către componentă, se reprezintă cu simbolul unui cerc.
• Solicitată – necesară componentei, se reprezintă cu un semicerc.
Interfața furnizată

Interfața solicitată
Portul
• Porturile sunt reprezentate folosind un pătrat de-a lungul marginii unei
componente.
• Un port este adesea folosit pentru a ajuta la expunerea interfețelor necesare și
furnizate ale unei componente.
• Este o fereastră explicită într-o componentă încapsulată. Toate interacțiunile în
și din astfel de componente trec prin porturi.
• Fiecare port furnizează sau necesită una sau mai multe interfețe specifice.

Port
 Relația de dependență

O linie întreruptă îndreptată spre furnizorul componentei

Relații în Clasele incluse în componenta client pot moșteni, instanția sau

utiliza clasele incluse în componenta furnizorului
diagrama de
componente Pot fi, de asemenea, relații de dependență între componente și
interfețe ale altor componente

Relația de compunere

Descrie componente incluse fizic în alte componente

Modelarea codului sursă
• Identificați setul de fișiere de cod sursă necesare și modelați-le ca și componente
cu sterotipul <<file>>.
• Pentru sisteme mai mari, utilizați pachete pentru a afișa grupuri de fișiere de cod
sursă.
• Descrieți valori etichetate care să indice informații precum numărul versiunii
fișierului cod sursă, autorul acestuia și data ultimei modificări.
• Modelați dependențele de compilare dintre aceste fișiere folosind dependențe.
Modelarea unei distribuții executabile
• Identificați setul de componente executabile pe care doriți să le modelați. Puteți
identifica toate componentele dintr-un singur nod sau distribuirea componentelor
pe toate nodurile din sistem.
• Specificați stereotipul fiecărei componente din acest set (exemple: executabile,
biblioteci, tabele, fișiere și documente).
• Pentru fiecare componentă, luați în considerare relația sa cu vecinii săi. Cel mai
adesea, aceasta va implica interfețe oferite și furnizate. Într-un model cu nivel
ridicat de abstractizare, se pot elimina interfețele, arătând numai dependențe
dintre componente.
Modelarea dependențelor cu pachete
Exemplu diagramă de componente -1
Exemplu diagramă de componente -2
Exemplu diagramă de componente -1
 O diagramă de desfășurare reprezintă relațiile dintre componentele
hardware utilizate în infrastructura fizică a unui sistem informatic.

Diagrama de Pentru un sistem informatic distribuit care va utiliza o rețea pe o zonă

extinsă, poate să fie folosită pentru a arăta relațiile de comunicare
desfășurare dintre diferitele noduri din rețea.

Poate include și componentele software și modul în care acestea sunt

alocate peste arhitectura fizică sau infrastructura unui sistem
informatic.

Atunci când include și componente, o diagramă de desfășurare

reprezintă mediul necesar pentru execuția componentelor software.
Diagrama de desfăşurare – notații
Element Reprezentare
Nodul:
▪ Este o resursă de calcul, de exemplu un computer client, un server, o
rețea separată sau un dispozitiv de rețea individuală.
▪ Este etichetat cu numele său.
▪ Poate conține un stereotip pentru a eticheta în mod specific tipul de
nod reprezentat, de exemplu, dispozitiv, stație de lucru client, server
de aplicații, dispozitiv mobil etc.

Artefactul:
▪ Este o specificare a unei componente software.
▪ Este etichetat cu numele său.
▪ Poate conține un stereotip pentru a marca în mod specific tipul de
artefact (fișierul sursă, tabelă de baze de date, fișier executabil).

Calea de comunicare:
▪ Reprezintă o asociere între două noduri.
▪ Permite nodurilor să schimbe mesaje.
▪ Poate conține un stereotip pentru a eticheta în mod specific tipul de
cale de comunicare reprezentat (Internet, serial, paralel). Aceasta
poate fi doar denumită sau poate fi calificată (agregare, compunere,
dependență, generalizare etc.)
Tipuri de noduri
• Diagramele de desfăşurare conţin două tipuri de noduri: dispozitive și mediile de
execuţie.
✓ Dispozitivele (Device) sunt resurse de calcul cu capacități de procesare și
capacitatea de a executa programe (calculatoare, laptopuri și telefoane mobile).
✓ Mediile de execuţie (EEN – Execution Environment Node) sunt noduri care
conțin medii software capabile să execută alte entități software precum sisteme
de operare, servere web (Apache sau Microsoft's Internet Information
Server (IIS) sau Java Runtime Environment (JRE)).
Reprezentarea componentelor în noduri
• Diagramele de desfăşurare pot fi utilizate pentru reprezentarea componentelor
ce pot aparţine anumitor noduri prin imbricarea grafică a simbolului componentei în
cadrul simbolului ce reprezintă nodul.
Exemplu diagramă de desfășurare -1
Exemplu diagramă de desfășurare -2
Proiectarea sistemelor
informatice

Seminar 9 - Proiectarea
❑ Diagrama de clase în proiectare
❑ Proiectarea bazei de date
❑ Proiectarea interfețelor
1
Diagrama detaliată de
clase
Etapa de proiectare
 Se parcurg pe rând cazurile de utilizare. Se aleg clasele
domeniului care sunt implicate în cazul de utilizare. Se
Diagrama de adaugă noi clase în funcție de specificul implementării.

clase la Se adaugă o clasa controller care sa fie responsabilă pentru

proiectare cazul de utilizare.

Se determină cerințele de vizibilitate a navigării.

Se completează atributele fiecărei clase cu vizibilitate și tip. Se

identifica responsabilitățile fiecărei clase și se completează
metodele specifice.
Exemple de clase stereotipe uzuale
Clasele stereotipe conțin informații adiționale despre semnificația clasei, cu scopul
de a face modelul mai ușor de înțeles.

• entitate (<<entity>>) – o clasă pasivă, care nu iniţiază interacţiuni;

• control (<<control>>) – iniţiază interacţiuni, conţine o componentă
tranzacţională şi este separator între entităţi şi limite;
• limită (<<boundary>>) – este aflată la periferia sistemului, dar în interiorul
său. Reprezintă limita de legătură cu actorul sau cu alte sisteme informatice;
• enumerare (<<enumeration>>) - este folosită pentru definirea tipurilor de
date ale căror valori sunt enumerate.
• primitivă (<<primitive>>) - o formă de clasă care reprezintă tipuri de date
predefinite, cum ar fi tipul Boolean.
Vizibilitatea navigării
• Abilitatea unui obiect de a vedea și interacționa cu alt obiect
• Realizată prin adăugarea într-o clasă a unei variabile referință la obiect
• Apare ca o săgeată pe capătul asocierii – Clientul poate vedea și
interacționa cu Rezervare
Reguli pentru navigabilitate
• Asocierile unu la mulți care indică o relație superior-subordonat
asigură navigarea de la superior la subordonați

• Asocierile obligatorii în care obiectele dintr-o clasă nu pot să

existe fără obiectele din altă clasă asigură, de obicei, navigarea
de la clasa mai independentă la cea mai dependentă.

• Când un obiect are nevoie de informații de la un alt obiect, ar

putea fi nevoie de o sageată de navigare.
Exemplu: transformarea diagramei de clase
Metodele claselor
• Se poate folosi tehnica CRC – Class, Responsibility,
Collaboration cards
• Care sunt responsabilitatile unei clase si cum colaboreaza cu
alte clase pentru a realiza cazul de utilizare
• Se obtin prin brainstorming
• Se pot folosi diagramele de secventa detaliate – fiecare mesaj
receptionat de un obiect al unei clase trebuie sa aiba in
corespondenta o metoda in clasa respectiva
Exemplu de carduri CRC
Completarea
metodelor
Protecția în fața schimbării
⮚Un principiu al proiectării este de a separa părțile care sunt stabile de
părțile care suferă numeroase schimbări.
⮚Se separă formularele și paginile din interfața cu utilizatorul care au
probabilitate mare de a se modifica de logica aplicației.
⮚Conexiunea la baza de date și logica SQL care probabil se vor modifica se
păstrează în clase separate de logica aplicației.
⮚Se utilizează clase adaptor care se pot schimba pentru interacțiunea cu alte
sisteme.
Daca se alege între doua variante de proiectare, se va alege varianta care
⮚

oferă o protecție mai mare în fața schimbării.

 Relațiile de asociere la proiectare
• Asocierile indică o conexiune bidirecțională între clase. Ele vor fi implementate ca atribute în
definitiile claselor.
• De exemplu, relația Client- Rezervare ( unu la mulți)
Implementarea relatiilor de agregare: prin referinta
• Agregare partajata: un obiect va contine doar o referinta la al
doilea obiect; obiectul continut poate fi referit si de alte obiecte
• De exemplu, Factura- Serviciu
Implementarea relatiilor de agregare: prin valoare
• Agregare compusa: o copie a obiectului agregat
este inclusa, prin valoare. Obiectul continut nu e
partajat cu alte obiecte
 Implementarea relatiilor de generalizare
• O subclasă moștenește dintr-o superclasă trei elemente specifice: atribute,
operații și relații. O ierarhie practică a moștenirii este de obicei adâncă pe
maxim trei niveluri.
• De exemplu, pentru cele trei tipuri de plati, mecanismul de mostenire permite
reutilizarea elementelor din clasa de baza, Plata.
• Polimorfism: comportamentul polimorf implică, în timpul rulării, ca același mesaj
are efecte comportamentale diferite.
2
Proiectarea bazei de
date
- Schema ERD
- Scriptul de creare a BD
 Se pleaca de la modelul claselor domeniului

Proiectarea Se alege structura bazei de date: relationala, orientate obiect, tip graf,
bazei de tip mesaj, perechi cheie-valoare etc

date
Se proiectează arhitectura BD (distribuită, etc)

Se proiectează schema bazei de date (tabelele și coloanele în relațional)

Se proiectează restricțiile de integritate referențială
 Maparea obiectelor domeniului pentru SGBDR
1.Maparea tuturor claselor concrete ale domeniului în tabele. De asemenea dacă o clasă abstractă a domeniului are moștenitori direcți multiplii,
mapăm clasa într-o tabelă.

2.Mapăm atributele cu valoare unică în coloane ale tabelei

3.Mapăm metodele în proceduri stocate sau module de program
4.Mapăm agregările și relațiile de asociere cu multiplicitate unu-la-unu într-o coloană care poate stoca cheia tabelei asociate ex: adăugăm o cheie
externă tabelei. Facem acest lucru pentru ambele capete ale relației.

5.Mapăm atributele multi-valoare și grupurile repetitive în tabele noi și creăm asocierei 1-n de la tabela originală către cele noi.
6.Mapăm agregările și relațiile de asociere cu multiplicitate mulți-la-mulți într-o nouă tabelă de legătură între cele 2 tabele originale. Copiem cheile
primare din ambele tabele în noua tabelă.

7.Pentru relații de agregare și asociere de tip mixt, copiem cheia primară din partea 1 a relației (1..1 sau 0..1) într-o nouă coloană în tabela aferentă
laturii mulți (1..* sau 0..*) a relației care poate stoca cheia tabelei de legătură ex: adăugăm o cheie externă tabelei de pe latura mulți a relației.

8.a. Ne asigurăm că cheia primară a subclasei este aceeași ca și cheia primară a superclasei. Multiplicitatea acestei noi asocieri de la subclasă
la superclasă ar trebui sa fie 1..1. SAU

8. b. Aplatizăm ierarhia de moștenire prin copierea atributelor superclasei în toate subclasele și eliminarea superclasei din model.
Relațiile de moștenire
a) Cel mai simplu mod este să mapăm toate atributele din
clasa părinte, precum și subclase, pe coloanele unui
singure tabele. Spațiu irosit: când un obiect Card este
stocat în acest tabel anume, acesta ar lăsa coloanele
specifice Cash si Banca necompletate. (varianta din
imagine, preferata de VP)
b) Creați tabele pentru toate clasele pentru copii și
adăugați-i atributele clasei părinte. Această abordare
devine mai dificilă pentru mai multe niveluri de
moștenire.
c) Creați tabele separate atât pentru clasa părinte, cât și
pentru copii. Aceste tabele sunt apoi legate cu ajutorul
cheii primare a tabelei care reprezintă clasa părinte
(id_plata)
 Pasi de urmat in Visual Paradigm
• Pentru clasele persistente se va adauga stereotipul <<ORM Persistable>>
• Se genereaza automat modelul entitate asociere (Synchronize to entity-
relationship diagram)
• Se fac rafinarile dorite pe modelul ERD
• Se genereaza baza de date in limbajul dorit (sau se genereaza scriptul DDL)

• Vezi tutorialul pentru Generarea bazei de date pe online.ase.ro

2
Proiectarea interfetelor
- Interfata cu utilizatorul
 Se finalizeaza diagramelor de cazuri de utilizare şi a unor prime
versiuni stabile ale diagramelor de interacţiune şi de clase.

Se recomandă implementarea unui prototip al sistemului informatic.

Proiectarea Acest prototip se numeşte prototip de interfaţă.

interfetelor Ajuta la rafinarea relaţiilor dintre actori şi clasele de interfaţă.

Are rolul de a obţine feedback din partea beneficiarului (clientului)

asupra aspectului vizual al aplicaţiei.
Proiectarea interfețelor
• Primul pas - investigarea aşteptării actorilor asupra interfeţei prin
completarea unor chestionare specifice formate din următoarele
întrebări:
1. ce nivel de pregătire (informatică) necesită actorul pentru a realiza o anumită
funcţionalitate?
2. actorul are experienţă de lucru în medii bazate pe ferestre?
3. actorul are experienţă în utilizarea altor sisteme de automatizare a procesului
modelat?
4. este necesară consultarea unor documente/cataloage în paralel cu utilizarea
aplicaţiei?
5. actorul doreşte implementarea unor facilităţi de tip ‘salvare/restaurare’?
Proiectarea interfețelor
• Scopurile prototipului sunt:
• stabilirea unor cerinţe ale interfeţei pentru funcţionalităţi
cheie ale aplicaţiei;
• se demonstrează clientului (într-o formă vizuală) că cerinţele
proiectului au fost bine înţelese şi sunt realizabile;
• începerea etapei de dezvoltare a elementelor standard ale
interfeţei.
Proiectarea interfețelor
• Se utilizează hărţi (diagrame) de structură a ecranului în
care se descrie fluxul aplicaţiei urmând căile principale
ale cazurilor de utilizare.
• Mod de reprezentare:
• forme pătrate pentru reprezentarea ferestrelor modale (necesită un
răspuns dat de utilizator pentru a se putea continua o activitate).
• forme pătrate cu colţurile rotunjite Pentru reprezentarea ferestrelor
ne-modale
• Direcţia de traversare arată calea de navigare a ferestrelor.
Proiectarea interfețelor
Ferestre care conţin tab-uri

Diagramă de structură a ecranului

Proiectarea interfeței – exemplu (vezi tutorial VP)
https://balsamiq.com/tutorials/articles/firstwireframe/

Proiectarea interfeței – Balsamiq

•Exemplu aplicatie mobile banking:
https://balsamiq.com/tutorials/articles/mobileapplication/

•Exemplu aplicatie web:

https://balsamiq.com/tutorials/articles/firstwireframe/
Proiectarea sistemelor
informatice
Seminar 8 - Limbajul BPMN
Partea 2
Modelarea tranzacțiilor
✓ Termenul „tranzacție” este utilizat în contexte diferite.

✓ De exemplu, există tranzacții comerciale, cum ar fi un transfer de bani dintr-un

cont bancar în altul.
✓ În informatică, în special tranzacțiile cu baze de date sunt bine cunoscute.

✓ Tranzacțiile sunt întotdeauna unități complete de lucru.

✓ O tranzacție este efectuată în totalitate sau deloc.

✓ În cazul situațiilor excepționale sau erorilor, tranzacția trebuie anulată.

✓ Putem trata părți din procesele de afaceri ca și tranzacții.

✓ Un exemplu tipic este rezervarea unei călătorii care implică rezervări

separate pentru un zbor și un hotel.
Modelarea tranzacțiilor– compensare

▪ Subprocesul „Procesare comandă” este o tranzacție.

▪ Acesta va fi întrerupt atunci când apare evenimentul „Primeste anulare comada”.
▪ Anularea unui sub-proces presupune activități suplimentare.
▪ Când se primește un mesaj de anulare, efectele activităților terminate sunt inversate.
▪ Acest lucru poate fi atins prin definirea activităților compensatorii pentru activitățile subprocesului:
“Despacheteaza produse” și “Pune produse in depozit”.
 O colaborare este o interacțiune sincronizată a două sau
Diagrama de mai multe procese.
colaborare
O astfel de interacțiune se mai numește „coregrafie”.

Diagramele de colaborare sunt utile în special pentru

documentarea cooperării mai multor companii.
Colaborările sunt modelate cu două sau mai multe containere,
fiecare container conținând un proces separat.
Diagrama de colaborare - exemplu
Denumirea containerelor într-o diagramă de
colaborare

Rol partener

Numele procesului
Modelarea fluxurilor de mesaje/secvențe
✓ Fluxurile de mesaje sunt permise numai între containere diferite, dar nu în cadrul unui container.

✓ Fluxurile de secvență nu pot conecta activități ce aparțin unor procese diferite, doar în cadrul
aceluiași container
Modelarea fluxurilor de mesaje/secvențe
Fluxuri de mesaje către containere de tipul
‘Cutie neagră’
✓ Se pot modela parteneri de colaborare pentru care se specifică doar containerul care îi
reprezintă, nu și procesul desfășurat la nivelul acestuia.
Fluxuri de mesaje către containere de tipul
‘Cutie neagră’
✓ Dacă numai mesajele schimbate și ordinea lor sunt relevante, ambele containere pot fi
modelate fără procesele lor.

Solicitant

Organizație
Procese publice și private
✓ Un proces privat reprezintă un proces intern modelat cu toate detaliile sale.
Procese publice și private
✓ Un proces public reprezintă o viziune simplificată asupra procesului desfășurat prezentată
parternerului de dialog dintr-o diagramă de comunicare..
Colaborare – exemplu
Proiectarea sistemelor
informatice
Seminar 7 - Limbajul BPMN
Partea 1
 Standard creat și întreținut de OMG, similar
limbajului UML.

Business Process
Modelele BPMN pot fi create în scopul identificării,
Model and Notation validării, îmbunătățirii sau automatizării
(BPMN) proceselor.

Permite optimizarea proceselor din lumea reală,

prin simulare.
BPMN – elemente de bază
 Obiecte de flux
Acțiuni

Reprezentare condensată
și extinsă a unui
subproces
Evenimente - exemplu

1. Eveniment de început care recepţionează un mesaj.

2. Eveniment intermediar care recepţionează un mesaj.
3. Eveniment intermediar care trimite un mesaj.
4. Eveniment final care trimite un mesaj.
5. Eveniment de început care recepţionează un mesaj
fără a întrerupe o altă activitate.
6. Eveniment intermediar care recepţionează un mesaj
fără a întrerupe o altă activitate.
Evenimente
Porți exclusive
Porți inclusive şi paralele
Porți complexe
Porți bazate pe evenimente
Obiecte de conectare
Fluxuri de secvenţă condiţionale
Client fidel
Solicita plata la
60 de zile

Stabileste conditii de Solicita plata la

plata pentru client 30 de zile

Solicita plata la
10 de zile
Client nou

Fluxuri de mesaj

Client
Cotatie de pret Oferta

Mesaj care Mesaj care nu

initiaza initiaza
Furnizor
Obiecte de partiționare
Containere
Client

Aduce produsul Primeste bon

Cere reparatie Preda produs
defect de receptie
Produsul nu mai
functioneaza
Service

Raporteaza Intocmeste bon Receptioneaza

Verifica produs
defectiuni de receptie produs
Obiecte de partiționare
Culoare

Refuza cererea
Vanzari

Primeste cerere Cerere refuzata

de produse NU Transmite
Calculeaza pret
oferta
Cerere onorata
Companie

DA
Depozit

Verifica stoc

Produse in stoc?
Management

Aproba discount
Obiecte de date și artefacte

Date de intrare
Date de iesire

Desfacere
Date client
Factura

Produse comandate Produse in stoc? Aviz de insotire a

marfii
DA
Primeste Intocmeste Impacheteaza si
Verifica stoc Pregateste livrare
comanda factura incarca produse

NU

Instiinteaza client Plan de transport

BD Produse
Date stocate
Bune practici
✓ Numele unei acțiuni/ subproces începe cu un verb.

✓ O poartă nu realizează acțiuni – Rolul acesteia este de a evalua condiții sau de a

aștepta producerea unor evenimente.
✓ Fluxurile de secvență nu pot traversa containerele – Pentru interacțiunea dintre
participanți se folosesc fluxuri de mesaj.
✓ Folosiți cu precauție fluxurile de secvență condiționale – Întotdeauna mulțimea
condițiilor reprezentate de fluxurile de ieșire trebuie să aibă un rezultat valid.
✓ Utilizați cu precădere perechi de porți de același tip - Acest lucru va crește
lizibilitatea modelului și va facilita validarea acestuia.
✓ Toate acțiunile realizate de un participant se includ în același container – Ulterior,
containerul poate fi partiționat în culoare.
✓ Pot exista mai multe evenimente de început sau de sfârșit într-o diagramă de
proces – Pentru a elimina confuziile, acestea trebuie denumite în mod diferit.
Aprofundăm- 1
În exemplul din figură subprocesul Achiziție:

Variante :
a) este întrerupt de evenimentul Livrare întârziată
b) nu este întrerupt de evenimentul Livrare întârziată
c) nu este întrerupt de evenimentul Indisponibil
d) nu poate fi întrerupt
Aprofundăm- 2
Porțile inclusive în limbajul BPMN:
1. pot avea mai multe fluxuri de ieșire
2. pot avea un singur flux de ieșire
3. nu evaluează condiții
4. evaluează mai multe condiții

Variante :
a) 1+4
b) 1+3
c) 2+3
d) 2+4
Aprofundăm- 3
Evenimentele în limbajul BPMN desemnează:
a) ceva ce se realizează în cadrul unui proces
b) ceva ce se întâmplă în timpul unui proces
c) ceva ce controlează divergenţa sau convergenţa unor fluxuri de activităţi
d) ceva ce descrie ordinea elementelor din flux
Aprofundăm- 4
Să se asocieze tipuri potrivite, specifice BPMN, pentru activitățile de mai jos.
Să se reprezinte într-un instrument de tip CASE.
Aprofundăm- 5

Ce tipuri de divergențe
se modelează?
Aprofundăm- 6
Descrieți scenariile modelate în diagramele următoare.
Exemplu practic - 1

A) Să se modeleze procesul de onorare a comenzilor unei companii producătoare

de produse finite. Descrierea procesului este următoarea:
Odată cu primirea unei comenzi de cumpărare, aceasta este onorată numai
dacă produsul este în stoc, iar în caz contrar procesul se finalizează prin
respingerea comenzii. Dacă produsul se află în stoc, atunci acesta este preluat
din depozit și comanda este confirmată. Ulterior, se realizează în mod
independent două grupe de acțiuni: pe de o parte, se preia adresa de livrare și
se livrează produsul, iar pe de altă parte, se emite factura și se primește
confirmarea plății. La final, comanda este arhivată și procesul se încheie.
Exemplu practic - 2
B) Să se extindă diagrama de procese modelată anterior cu posibilitatea de a
fabrica un produs, în situația în care acesta nu este în stoc. Se va lua în
considerare descrierea următoare:
Dacă produsul solicitat nu este în stoc, atunci acesta trebuie să fie fabricat
înainte ca gestiunea comenzii să poate continua. Pentru fabricarea unui produs
trebuie comandate materiile prime necesare. Compania lucrează cu doi furnizori
preferați care îi furnizează diferite tipuri de materii prime. Se verifică
disponibilitatea materiile prime necesare în ofertele furnizorilor. În funcție de
produsul care va fi fabricat, materiile prime pot fi comandate fie de la furnizorul
1, fie de la furnizorul 2 sau de la amândoi. Odată ce materiile prime sunt
disponibile, produsul poate fi fabricat și comanda poate fi confirmată. Pe de altă
parte, dacă produsul este în stoc, acesta este preluat din depozit înainte de a
confirma comanda. În ambele cazuri, procesul continuă normal.
Exemplu practic - 3

C) Să se adauge la diagrama anterioară datele necesare pentru executarea

procesului. Au fost identificate următoarele tipuri de date:
- Obiecte de date: Comanda (cu stările Confirmată și Plătită), Materii prime,
Produs (cu starea Împachetat), Adresa de livrare, Factura
- Date stocate: Catalog furnizori, BD Depozit, Produse depozit, BD Comenzi
De lucru - exercițiul 1
Modificați următorul exemplu pentru a obține o diagramă BPMN corectă.
Desenați modelul corectat.

De lucru - exercițiul 2
Identificați corect tipurile de porți din figura de mai jos. Desenați modelul corectat.
De lucru - exercițiul 3
Modelați următorul fragment al unui proces de afaceri pentru evaluarea
cererilor de împrumut.
O cerere de împrumut primită este aprobată dacă trece de două verificări: (1)
evaluarea riscului împrumutului solicitantului și (2) evaluarea proprietății pentru
care a fost solicitat împrumutul, efectuată de către un evaluator imobiliar.
Evaluarea riscurilor necesită o verificare, în prealabil, a istoricului de credit al
solicitantului. După efectuarea atât a evaluării riscului împrumutului, cât și a
evaluării proprietății, un ofițer de împrumut poate evalua eligibilitatea
solicitantului. Dacă solicitantul nu este eligibil, cererea este respinsă, altfel
pachetul de acceptare este pregătit și trimis solicitantului.
Nu este necesar să se modeleze culoare pentru a identifica roluri.
Proiectarea sistemelor
informatice
Seminar 6 - Limbajul UML
Diagrama de mașini cu stări
Diagramele de interacţiune
1
Diagrama mașini cu stări
Machine state diagram
 Modelează starea dinamică a unui obiect specific.

Diagrama de Starea reprezintă o perioadă sau o situaţie din existenţa unui obiect
maşină cu care satisface în acel moment anumite condiţii, efectuează anumite
activităţi sau aşteaptă anumite evenimente.
stări
Evenimentele determină tranziţia unui obiect dintr-o stare în alta.

Nu toate evenimentele sunt aplicabile în contextul tuturor stărilor.

Pot exista condiţii care să condiţioneze apariţia unui anumit eveniment.
Stări
• Stare - este reprezentată ca un dreptunghi cu colţuri rotunjite.
• Stare compusă – este o stare care conţine substări (stări imbricate).
• Starea submaşină – folosită pentru a reutiliza o parte a unei diagrame stări în alte
diagrame de stări; comportamentul este activat ca şi un apel de subrutina în programare
Stare iniţială şi stări finale
• Stare iniţială
• Pseudostare (obiectul nu poate ramane în acea stare)
• Semnifică începutul vieţii unui obiect.
• Stare finală
• Stare reală
• Marcheaza sfarşitul secvenţei de stări
• Obiectul poate ramâne în starea finala pentru totdeauna
• Nod de terminare
• Pseudostare
• Termină maşina de stări
• Execuția se termină imediat fără a executa activități de ieșire
Tranziţii
• Obiectul tranzitează dintr-o stare în alta când apare un eveniment şi
când sunt îndeplinite anumite condiţii.
• Tranziţia este reprezentată ca o săgeată de la o stare existentă către o
stare de intrare / ţintă.
• Tranziţia poate conţine:
✓ Declanşator: este cauza unei tranziţii care poate fi un de eveniment, o
schimbare într-o condiţie sau trecerea timpului.
✓ Condiţie: o condiţie care trebuie să fie adevărată pentru ca declanşatorul
să determine tranziţia.
✓ Efect: Acţiune care va fi invocată de obiect ca urmare a tranziţiei.
Activități
• Cu excepţia stării iniţiale şi a celei finale, fiecare stare are un nume,
atributele proprii unei stări, acţiunile şi activităţile efectuate.
• Acţiunile speciale includ:
• Entry / intrare - acţiune efectuată la intrarea într-o stare.
• Exit / ieşire - acţiune efectuată la ieşirea dintr-o stare.
• Do / acţiune efectuată pe parcursul unei stări; evenimentele externe pot întrerupe acţiunile Do.
• Defferable trigger – eveniment intern, care nu declanseaza o tranzitie la altă stare.
Decizii
• Decizie – o pseudostare ce realizează o bifurcaţie condiţională. Evaluează
condiţiile declanşatorilor tranziţiilor de ieşire pentru a alege o singură tranziţie
de ieşire.
Exemple de maşini cu stări
Bune practici – diagrame de stări
⮚Se recomandă crearea unei diagrame de mașini cu stări pentru obiectele al căror
comportament se schimbă în funcție de starea obiectului.
⮚Pentru a respecta convențiile de citire de la stângă la dreapta și de sus în jos, starea
inițială trebuie desenată în colțul din stânga sus al diagramei și starea finală trebuie
desenată în partea dreaptă jos a diagramei.
⮚Numele stărilor trebuie să fie simple, intuitive și descriptive. Acestea vor fi denumite
print-un adjectiv sau printr-o expresie care desemnează o caracteristică.
⮚Toate condițiile mutual exclusive este nevoie să se excludă reciproc. Este necesară
verificarea acoperirii tuturor situațiilor posibile.
⮚Toate tranzițiile ar trebui să aibă asociate un eveniment. În caz contrar, starea
obiectului nu s-ar putea schimba niciodată.
⮚ Stările unui obiect trebuie să se regăsească în atributele clasei respective
⮚ Acţiunile realizate în diferite stări se vor regăsi ca operaţii ale clasei respective
 Lucru la seminar
Să se întocmească diagrama de stare pentru clasa cameră din scenariul de mai jos.

Scopul proiectului este realizarea aplicaţiei informatice pentru gestiunea activităţii unei unităţi
hoteliere. În vederea cazării, un client poate solicita rezervarea uneia sau mai multor camere prin e-
mail sau telefonic. Pentru aceasta furnizează recepţionerului informaţii privind perioada de cazare şi
tipurile de camere solicitate. Clienţii vor beneficia de reduceri dacă rezervă cel puţin 3 camere sau dacă
perioada de cazare depăşeşte 5 zile. Recepţionerul verifică disponibilitatea camerelor şi îl înştiinţează
pe client de acest lucru precum şi de costul estimat al cazării. Dacă nu există camere disponibile
conform solicitării, recepţionerul poate oferi clientului alternative. De asemenea, clientul poate solicita
un discount (suplimentar sau nu), iar recepţionerul va decide fezabilitatea discountului, fiind asistat
obligatoriu de managerul hotelului. În situaţia în care clientul este de acord cu preţul propus, se va
proceda la realizarea rezervării. Pentru clienţii noi, recepţionerul solicită datele de identificare, pe care
le introduce în aplicaţie.
Odată ajuns la hotel, şi dacă a făcut în prealabil o rezervare, clientul va furniza datele de identificare ale
sale şi/sau ale rezervării şi se face cazarea. Dacă nu există o rezervare, se va verifica disponibilitatea
camerelor pentru perioada cerută. Atunci când se găseşte o astfel de cameră, se face cazarea. La finalul
sejurului, recepţionerul întocmeşte o listă cu toate serviciile solicitate de client şi preţul acestora. Lista
trebuie validată de client, după care se întocmeşte factura finală. Factura poate fi plătită parţial sau
integral, prin transfer bancar, numerar sau folosind un card bancar. Totodată, înainte de a părăsi
hotelul, clientul este rugat să completeze un formular prin care să evalueze serviciile oferite de unitatea
hotelieră. După eliberarea camerei, camerista verifică starea acesteia și informează recepția.
2
Diagramele de interacţiune
❑ Diagrama de secvenţă
❑ Daigrama de colaborare
 Modelează aspectele dinamice ale sistemului.

Diagramele Sunt alcătuite dintr-un set de obiecte şi relaţiile dintre ele, incluzând şi
de mesaje pe care obiectele le trimit de la unul la altul.

interacţiune Vom aborda două tipuri de diagrame de interacţiune: diagrama de

secvenţă şi diagrama de comunicare ( în UML 1.4 numită de
colaborare).

Cele două diagrame sunt echivalente din punct de vedere semantic şi se

pot transforma una din alta.
 Diagrama de secvenţă
• Este o diagramă de interacţiune formată din obiecte, mesajele care se schimbă între acestea şi
dimensiunea temporală reprezentată progresiv pe verticală.
• Subliniază ordinea mesajelor în funcţie de timp.
• Obiectele sunt plasate în marginea de sus a diagramei, de-a lungul axei OX, de la stânga la
dreapta.
⮚ Ele sunt aranjate în orice ordine care permite simplificarea diagramei.
⮚ De obicei, obiectele care încep interacţiunea se aşează la stânga iar obiectele care
urmează în partea dreaptă.
⮚ Existenţa obiectelor este reprezentată prin liniile de viaţă ale acestora.
Capătul liniei de viaţă

Corpul liniei de viaţă

 Obiectele
• Linia de viaţă a obiectelor: linie verticală care reprezintă existenţa unui obiect de-a
lungul unei perioade de timp. Majoritatea obiectelor există pe toată durata
interacţiunii, având linia de viaţă trasată de la vârful diagramei până la bază. Alte
obiecte pot fi create pe parcursul interacţiunii.
• Specificarea execuției: un dreptunghi înalt şi subţire care indică perioada de timp în
care obiectul realizează o acţiune. Capătul de sus al dreptunghiului este aliniat la
începutul acţiunii iar capătul de jos la sfârşitul acţiunii.
• Obiectele pot fi reprezentate folosind stereotipurile actor, boundary, entity şi control.
 Mesaje - 1
• Mesajele sunt reprezentate sunt forma unor arcuri. Acestea
pornesc de la linia de viaţă a unui obiect şi se opresc la linia de viaţă
a altui obiect.
• Mesajele pot fi de mai multe tipuri şi pot include parametri
• Mesaj de tip apel (call) reprezintă un mesaj sincron, obiectul care
trimite mesajul aşteaptă răspunsul din partea obiectului care primeşte
mesajul. Cererea implică faptul că receptorul va executa una dintre
operaţiile sale.

• Mesaj tip raspuns (return) – poate fi omis dacă continutul şi locul sunt
evidente

• Mesaj asincron - emiţătorul îşi continuă activitatea fără să aştepte

răspuns

• Un obiect poate trimite mesaje şi către sine - autoapelare. Un astfel

de mesaj poate semnifica apelul recursiv al unei operaţii sau o metodă
care apelează altă metodă a aceluiaşi obiect.
 Mesaje -2
• Mesajele de creare (create) şi distrugere (destroy)
a unui obiect încep şi respectiv încheie linia de viaţă
a unui obiect. Acestea sunt opţionale şi se folosesc
atunci când se doreşte specificarea explicită a
acestor evenimente.

• Mesajul de distrugere poate genera distrugeri

ulterioare ale unor obiecte pe care acesta le
conţine prin compunere. După distrugere, un
obiect nu mai poate fi creat din nou pe acceaşi linie
de viaţă.
Ordinea executării mesajelor
a ) Pe aceeaşi linie de viaţă b) Pe linii de viaţă diferite

Se întâmplă înainte

c) Pe linii de viaţă diferite, care schimbă mesaje

Diagrama de secvenţă - exemplu
Fragmente combinate
• Diagramele de secvenţă nu sunt folosite pentru a reprezenta logică
procedurală complexă, există mecanisme create în acest sens: fragmentele
combinate.
• Un fragment combinat reprezintă una sau mai multe secvenţe de
procesare incluse într-un cadru şi executate în anumite circumstanţe.
Fragmente combinate
• Există 12 tipuri predefinite de operatori

• Frecvent utilizate sunt fragmente de tip:

• Alternative (Alt) care modelează construcţiile
de tipul if..then..else.
• Repetitive (Loop) care conţin o serie de
interacţiuni ce se vor repeta de mai multe ori.
• Paralele (Par) care modelează procesarea
concurentă.
• Optionale (Opt) care modeleaza interactiuni
optionale
Fragmente combinate – exemplul 1
Fragmente combinate – exemplul 2
Diagrama de comunicare
• Diagrama de comunicare (colaborare - nume în UML 1.4) este o diagramă
de interacţiune care subliniază organizarea structurală a obiectelor care
trimit şi primesc mesaje.
• Grafic, o diagramă de colaborare este o colecţie de vârfuri şi arce.
• Reprezintă aceleaşi informaţii ca şi diagrama de secvenţă, dar subliniază
organizarea obiectelor care participă la interacţiune.
• Obiectele sunt plasate primele, ca vârfuri ale unui graf, se trasează
legăturile care conectează obiecte, ca arcuri în acest graf, apoi se adaugă
acestor legături mesajele pe care obiectele le primesc sau le trimit.
• Pentru a indica ordinea, mesajul trebuie prefixat cu un număr începând de
la 1 şi crescând.
Diagrama de comunicare – exemplu
De reţinut!
• Cele două diagrame de interacţiune sunt echivalente şi o diagramă
poate fi convertită în cealaltă fără a se pierde informaţii.
• Pentru a transforma o diagramă în alta, în Visual Paradigm se face click
dreapta pe suprafaţa unei diagrame şi se selectează opţiunea Syncronize
to Communication/Sequence diagram, după caz.
• Diagrama de comunicare arată cum sunt legate obiectele în timp ce
diagrama de secvenţă pune în evidenţă şi mesajele returnate, precum şi
ordinea temporală a interacţiunilor.
Lucru la seminar
Să se întocmească diagramele de interacţiune pentru cazul de utilizare
“Rezervă camere ” din scenariul de mai jos.

Scopul proiectului este realizarea aplicaţiei informatice pentru gestiunea activităţii unei unităţi
hoteliere. În vederea cazării, un client poate solicita rezervarea uneia sau mai multor camere
prin e-mail sau telefonic. Pentru aceasta furnizează recepţionerului informaţii privind
perioada de cazare şi tipurile de camere solicitate. Clienţii vor beneficia de reduceri dacă
rezervă cel puţin 3 camere sau dacă perioada de cazare depăşeşte 5 zile. Recepţionerul
verifică disponibilitatea camerelor şi îl înştiinţează pe client de acest lucru precum şi de costul
estimat al cazării. Dacă nu există camere disponibile conform solicitării, recepţionerul poate
oferi clientului alternative. De asemenea, clientul poate solicita un discount (suplimentar sau
nu), iar recepţionerul va decide fezabilitatea discountului, fiind asistat obligatoriu de
managerul hotelului. În situaţia în care clientul este de acord cu preţul propus, se va proceda
la realizarea rezervării. Pentru clienţii noi, recepţionerul solicită datele de identificare, pe care
le introduce în aplicaţie.
Odată ajuns la hotel, şi dacă a făcut în prealabil o rezervare, clientul va furniza datele de
identificare ale sale şi/sau ale rezervării şi se face cazarea. Dacă nu există o rezervare, se va
verifica disponibilitatea camerelor pentru perioada cerută. Atunci când se găseşte o astfel de
cameră, se face cazarea. La finalul sejurului, recepţionerul întocmeşte o listă cu toate serviciile
solicitate de client şi preţul acestora. Lista trebuie validată de client, după care se întocmeşte
factura finală. Factura poate fi plătită parţial sau integral, prin transfer bancar, numerar sau
folosind un card bancar. Totodată, înainte de a părăsi hotelul, clientul este rugat să
completeze un formular prin care să evalueze serviciile oferite de unitatea hotelieră.
In cadrul acestei diagrame am
modelat un scenariu favorabil
de realizare a unei rezervari:
- exista o varianta de camera
disponibila
- se ajunge la un acord cu
privire la costuri.
Proiectarea sistemelor
informatice
Seminar 5 - Limbajul UML
Diagrama de activitate
 Ajută la reprezentarea vizuală a secvenţelor de
acţiuni prin care se doreşte obţinerea unui
rezultat.

Diagrama de Se poate realiza pentru unul sau mai multe

activitate cazuri de utilizare sau pentru descrierea unor
operaţii complexe.

Descrie fluxul de lucru dintr-un punct de

plecare până într-un punct de terminare,
detaliind căile de decizie care pot apărea într-
o activitate.
Activitate
• Activitatea - un comportament parametrizat reprezentat sub forma
unui flux coordonat de acţiuni.
• Specifică comportamentul definit de utilizator la diferite niveluri de
granularitate
• O activitate este un graf direcționat Parametru
de ieșire
➢ Nodurile: acțiuni și activități Nume activitate
<<preconditie>>
➢ Arce: pentru fluxul de control și de obiect <<postconditie>>
Parametru de
intrare

Nod Arc
Acțiune
• Acţiunea – reprezintă un singur pas în cadrul unei activităţi.
• Acțiunile sunt atomice, deci nu mai pot fi descompuse
• Acţiunea poate fi
➢ fizică, realizată de un factor uman
➢ electronică
• Există notații speciale pentru diferite tipuri de acțiuni, cum ar fi:
➢ acțiuni bazate pe evenimente
➢ acțiuni care apelează comportament
Constrângeri
• Constrângerile pot fi ataşate unei acţiuni, spre exemplu, sub forma
unor pre- şi post-condiţii.
• Se folosesc cuvintele cheie <<precondition>> şi <<postcondition>>.
Fluxuri (Arce)
• Conectează între ele activitățile și acțiunile și exprimă
ordinea de execuție. Condiție

• Arc flux de control – un arc pe diagramă care descrie modul

de transfer al controlului de la o acţiune la alta.
• Arc flux de obiecte - este un flux de-a lungul căruia sunt
transferate obiecte sau date. Flux de control

➢ Trebuie să aibă un obiect la cel puţin unul din capete. Flux de obiecte

➢ Există şi o notaţie prescurtată în care se pot folosi

calificatori (engl. pins) de intrare şi de ieşire

• Condiţie tranzitorie - un text pe un flux ce defineşte o Flux de obiecte

condiţie care trebuie să fie adevărată pentru a produce
tranziţia către următoarea acţiune.
Jetoane
• Mecanism virtual de coordonare care descrie cu exactitate execuția
➢ nu este inclus în notațiile diagramei
➢ mecanism care acordă acțiunilor permisiunea de execuție
• Dacă o acțiune primește un jeton, atunci acțiunea poate fi executată.
• Când o acțiune este finalizată, aceasta transmite jetonul următoarei
acțiuni, declanșând execuția acesteia
• Există două tipuri de jetoane: Actiune 1
➢ Jeton control: “permisiunea de execuție” pentru un nod
➢ Jeton obiect: transport date + “permisiunea de execuție” Actiune 2
Noduri
• Nod iniţial
➢ reprezintă punctul de început al diagramei
➢ transmite jetoane tuturor fluxurilor de ieșire
➢ păstrează jetoane până când nodurile succesive le acceptă
• Nodul final - există două tipuri de noduri finale:
➢ Nod final al activităţii reprezintă sfârşitul tuturor fluxurilor de control dintr-o
diagramă.
➢ Nod final al fluxului arată că procesul se opreşte în acel punct. Acesta denotă
sfârşitul unui singur flux de control.
Noduri decizionale şi de îmbinare
• Ambele se reprezintă sub forma unui romb şi pot fi denumite.
• Nod decizional (decision):
➢ nod în care intră un flux şi ies mai multe
➢ fluxurile de ieşire trebuie să fie însoţite de condiţii mutual
exclusive
➢ Jetonul alege o singură cale
• Nod de imbinare (merge):
➢ nod în care intră mai multe fluxuri şi iese unul singur
➢ transmite jetonul următorului nod
• Există și versiunea combinată a nodului decizional și de
îmbinare
Noduri de bifurcaţie şi sincronizare
• Ambele se reprezintă printr-o linie neagră îngroşată.
• Nod de bifurcaţie (fork):
➢ nod în care intră unul singur flux şi ies mai multe
➢ denotă începutul unor acţiuni paralele
➢ se realizează copii ale jetonului pentru toate arcele de ieșire
• Nod de sincronizare (join):
➢ nod în care intră mai multe fluxuri şi iese doar unul singur
➢ toate fluxurile care intră în sincronizare trebuie să ajungă în punctul
de sincronizare înainte ca procesarea să continue
➢ denotă sfârşitul unei procesări paralele
• Se poate realiza combinarea nodurilor de bifurcație și
sincronizare
Noduri - exemplificare
Acțiuni bazate pe evenimente
• Care trimit semnale

• Care acceptă evenimente

➢ Acțiune care acceptă eveniment

➢ Acțiune care acceptă eveniment de tip timp

Tratarea excepțiilor
• Definește modul în care sistemul trebuie să reacționeze într-o anumită
situație de eroare
• Handler-ul de excepții înlocuiește acțiunea în locul unde a apărut eroarea
Tratarea excepțiilor - Regiune dintr-o activitate care
poate fi întreruptă
• Definește un grup de acțiuni a căror execuție trebuie terminată imediat
dacă are loc un anumit eveniment. În acest caz, se execută un alt
comportament
Partiții

• Sunt culoare care arată cine sau ce execută acţiunile

într-o diagramă de activitate.
• Pot fi orizontale sau verticale.
• Separarea pe partiţii poate fi făcută în funcţie de
unitaţile organizaţionale, responsabilităţi etc.
• Realizează o mai bună structurare a diagramei
Bune practici – diagrama de activitate
✓ Plasați nodul de start în colțul din stânga sus al diagramei, pentru o mai
bună lizibilitate a acesteia.

✓ Orice diagramă trebuie să aibă cel puțin un nod de start și un nod de

finalizare.

✓ Verificați corectitudinea activităților de tip ‘gaură neagră’, care au un flux de

intrare dar niciun flux de ieșire. Cel mai probabil ați omis o tranziție.

✓ Verificați corectitudinea activităților de tip ’miracol’, care au fluxuri de ieșire

dar nu fluxuri de intrare. Doar activitatea de start poate avea un asemenea
comportament.
Bune practici – noduri
✓ Nodurile decizionale trebuie să reflecte activitatea anterioară.

✓ Un nod de bifurcație trebuie în mod normal să aibă și un nod de sincronizare

corespunzător.

✓ Nodul decizional are un singur flux de intrare.

✓ Nodul de îmbinare are un singur flux de ieșire.

✓ Nodul de bifurcație are un singur flux de intrare.

✓ Nodul de sincronizare are un singur flux de ieșire.

Bune practici – condiții
✓ Fiecare flux de ieșire dintr-un nod decizional trebuie să aibă o condiție.

✓ Condițiile trebuie să nu se suprapună. De exemplu: x<=0 și x>=0. Nu

este clar ce cale se va urma în situația în care x este 0.

✓ Condițiile trebuie să fie complete. De exemplu: x<0 și x>0 . Nu este

clar ce cale se va urma în situația în care x este 0.

✓ Folosiți condiții de tipul [altfel] pentru a acoperi toate condițiile

nespecificate explicit.
Bune practici – partiții
✓ Ordonați partițiile într-un mod logic.

✓ Utilizați partițiile când modelați procese liniare, nu procese ciclice.

✓ Încercați să evitați să includeți mai mult de cinci partiții într-o

diagramă.

✓ Folosiți partiții orizontale pentru modelarea proceselor de afaceri.

Aprofundăm- 1
Pentru diagrama de activitate din figură, care dintre următoarele secvențe de acțiuni este
posibilă în timpul execuției?

1. A → B → C → D
2. A → B → D → C
3. A → C → B → D
4. A → B → D
5. A → C

Variante (răspuns unic):

a) 1+2+3+4
b) 1+2+4
c) 1+2+3
d) 4+5
Aprofundăm- 2
Pentru diagrama de activitate din figură, care dintre următoarele secvențe de acțiuni este
posibilă în timpul execuției?

1. A → C
2. A → B → D
3. A → B → D → C
4. A → B → C

Variante (răspuns unic):

a) 1+3
b) 1+2
c) 3
d) 4
Aprofundăm- 3
Nodul de bifurcație (Fork) într-o diagramă de activitate are ca și caracteristici (răspuns
multiplu):
a) Este folosit pentru modelarea fluxurilor paralele
b) Este o alternativă a nodului decizional
c) Transmite jetoane către toate arcele de ieșire
d) Poate fi folosit doar în combinație cu nodul de sincronizare (Join)
Aprofundăm- 4

Identificați care dintre următoarele afirmații despre partițiile dintr-o diagramă de

activitate UML sunt adevărate (răspuns multiplu):
1. Partițiile grupează nodurile și arcele unei activități
2. Partițiile ajută la clarificarea modelului
3. Partițiile pot fi utilizate pentru a organiza responsabilitățile actorilor pentru
anumite acțiuni.
4. Partițiile nu trebuie să aibă o adâncime ierarhică mai mare decât unu
Aprofundăm- 5

Identificați care dintre următoarele noduri sunt elemente ale unei diagrame de
activitate în limbajului UML (răspuns multiplu):
a) Nod final al fluxului
b) Nod de sincronizare
c) Nod de tăiere
d) Nod de comunicare
e) Nod de bifurcație
f) Nod decizional
g) Nod de distribuție
Studiu de caz
Scopul proiectului este realizarea unui sistem informatic pentru gestiunea activităților de rezervare și cazare
ale unei unități hoteliere. În vederea cazării, un client poate solicita rezervarea uneia sau mai multor camere
prin e-mail, telefonic sau folosind site-uri specializate în rezervări hoteliere. Pentru rezervările prin email sau
telefonic, clientul furnizează recepționerului informații privind perioada de cazare și tipurile de camere
solicitate. Clienții vor beneficia de reduceri implicite dacă rezervă cel un număr minim de camere sau dacă
perioada de cazare depășește patru zile. Recepționerul verifică disponibilitatea camerelor și îl înștiințează pe
client de acest lucru precum și de costul estimat al cazării. Dacă nu există camere disponibile conform
solicitării, recepționerul poate oferi clientului alternative. De asemenea, clientul poate solicita un discount
suplimentar, iar recepționerul va decide fezabilitatea discountului, fiind asistat obligatoriu de managerul
hotelului. În situația în care clientul este de acord cu prețul propus, se va proceda la realizarea rezervării.
Pentru clienții noi, recepționerul solicită datele de identificare, pe care le introduce în aplicație. Nu se poate
acorda discount suplimentar pentru rezervările făcute prin intermediul site-urilor specializate.
Odată ajuns la hotel, și dacă a făcut în prealabil o rezervare, clientul va furniza datele de identificare ale sale
și/sau ale rezervării și se face cazarea. Dacă nu există o rezervare, se va verifica disponibilitatea camerelor
pentru perioada cerută. Atunci când se găsește o astfel de cameră, se face cazarea. La finalul sejurului,
recepționerul întocmește o listă cu toate serviciile solicitate de client, precum și prețul acestora. Lista trebuie
validată de client, după care se întocmește factura finală. Factura poate fi plătită parțial sau integral, prin
transfer bancar, numerar sau folosind un card bancar. Totodată, înainte de a părăsi hotelul, clientul este rugat
să completeze un formular prin care să evalueze serviciile oferite de unitatea hotelieră. După eliberarea
camerei, camerista verifică starea acesteia și informează recepția.
➢ Să se reprezinte în Visual Paradigm diagrama de activitate pentru activitatea de rezervare a camerelor.
 Studiu individual

Comerț Învățământ Servicii

electronic universitar medicale

Realizați o diagramă de activitate pentru una dintre cele trei categorii de sisteme
 Exercitii – diagrama de clase
● O echipă este formată din 11 jucători, dintre care unul este căpitan.

● O companie este formată din departamente. Departamentele sunt localizate în una sau mai multe clădiri
de birouri. Unul dintre birouri funcționează ca sediu central. Fiecare departament are un manager care
este recrutat din rândul angajaților săi.
 Exercitii – diagrama de clase
● Un colecționar deține una sau mai multe colecții. Pentru a se constitui o colecție sunt necesare cel puțin
2 obiecte.

● Într-o clinică medicală, un pacient care prezintă anumite simptome, poate realiza programări la medicii
clinicii. Atât medicii cât și pacienții trebuie să fie utilizatori ai sistemului.
Proiectarea sistemelor
informatice
Seminar 4 - Limbajul UML
Diagrama claselor
 Ansamblu de obiecte care au aceleaşi caracteristici şi contrângeri.

Caracteristicile unei clase sunt atributele şi operaţiile, prin care de

Definirea descriu proprietăți și comportamente .

unei clase Clasele abstracte nu pot fi instanţiate. Rolul lor este de a permite altor
clase să le moştenească, în vederea reutilizării caracteristicilor.

O interfaţă descrie un set de caracteristici şi obligaţii publice. Specifică,

de fapt, un contract. Orice instanţă care implementează interfaţa trebuie
să ofere serviciile furnizate prin contract.
Exemple de clase stereotipe uzuale
Clasele stereotipe conțin informații adiționale despre semnificația clasei, cu scopul
de a face modelul mai ușor de înțeles.
•entitate (<<entity>>) – o clasă pasivă, care nu iniţiază interacţiuni;
•control (<<control>>) – iniţiază interacţiuni, conţine o componentă
tranzacţională şi este separator între entităţi şi limite;
•limită (<<boundary>>) – este aflată la periferia sistemului, dar în interiorul său.
Reprezintă limita de legătură cu actorul sau cu alte sisteme informatice;
•enumerare (<<enumeration>>) - este folosită pentru definirea tipurilor de
date ale căror valori sunt enumerate.
•primitivă (<<primitive>>) - o formă de clasă care reprezintă tipuri de date
predefinite, cum ar fi tipul Boolean.
Atribute -1
•Fiecare atribut este descris cel puţin prin numele său.
•Se pot adăuga şi informaţii adiţionale, iar forma generală a unui atribut
este:
[vizibilitate][/]nume[:tip][multiplicitate][=valoare implicită] [{proprietate}]
•Vizibilitatea poate fi:
• + public: poate fi văzută şi folosită de oricine
• - private: numai clasa însăşi poate avea acces
• # protected: au acces clasa şi subclasele acesteia
• ~ package: numai clasele din acelaşi pachet pot avea acces
•/ simbolizează un atribut derivat
Atribute -2
•UML permite specificare multiplicităţilor pentru atribute, atunci când
dorim să definim mai mult de o valoare pentru un atribut. Au următoarea
semnificaţie:
Multiplicitate Sens
1 Exact 1 (implicit)
2 Exact 2
1..4 De la 1 la 4 (inclusiv)
3, 5 3 sau 5
1..* Cel puţin unul sau mai mulţi
* Nelimitat (inclusive 0)
0..1 0 sau 1

•Proprietate indică o proprietate suplimentară care se aplică atributului:

• {readonly}: atributul poate fi citit, dar nu modificat
• {ordered}, {unordered}: o mulţime ordonată sau neordonată
• {unique}, {nonunique}: mulţimea poate conţine sau nu elemente identice
Operații
•Forma generală a unei operaţii este:
[vizibilitate] nume ([direcţie] lista parametri) [:tip returnat] [{proprietate}]
•Vizibilitatea – aceeaşi ca şi la clase
•Direcţie - 'in' | 'out' | 'inout' | 'return'
•Tip returnat – dacă operaţia returnează ceva, adică este o funcţie
•Un exemplu de proprietate a unei operaţii: {query} - nu are efecte secundare, nu
schimbă starea unui obiect sau a altor obiecte, exemplu operaţiile de tip “get”.
Exemple de atribute: Exemple de operaţii:
• - varsta: Integer {varsta>18} • + setVarsta (out varsta: Integer)
• # nume:String[1..2]=“Ioana” • + getVarsta(in Id:String): Integer {query}
• ~ Id:String {unique} • - schimbaNume(inout nume:String)
• / sumaTotala:Real=0
Constrângeri
•O constrângere este o expresie care restricţionează un anumit element al diagramei de
clase.
•Aceasta poate fi o expresie formală (scrisă în Object Constraint Language - OCL) sau o
formulare semi-formală sau informală.
•Acestea sunt reprezentate între acolade.
•Pot fi scrise imediat după definirea elementului sau ca un comentariu.
•O constrângere poate avea şi un nume, astfel: {nume : expresie booleană }

Exemple de constrângeri OCL:

context Organizatie
inv: self. departamente→isUnique (nume)
inv: departamante.angajati→isUnique (cod)
Relația de asociere -1
1. Asocierea implică stabilirea unei relaţii între clase.
✔Relațiile de asociere între clase pot fi clasificate ca „utilizări” - deoarece reprezintă o clasă
folosind o altă clasă într-un anume fel.
✔Asocierea este mai cea frecventă și cea mai comună relație între două clase în orientarea
obiect.
✔Cele mai multe clase de asociere sunt coezive - adică lucrează împreună pentru a atinge un
obiectiv în cadrul sistemului.
Relația de asociere -2
•Asocierea dintre clase este caracterizată prin:
✔Denumire (opţională): reflectă natura relației dintre clase.
✔Multiplicităţi: arată câte obiecte alei unei clase care pot fi asociate cu un obiect
al clasei de la capătul opus al asocierii; se trec la cele două capete ale asocierii.
✔Roluri ale asocierii: se trec la fiecare capăt al asocierii şi conţin o descriere scurtă şi
reprezentativă de 1 – 2 substantive; arată modul de implicare a obiectului în relație.
✔Direcţie de navigare: legată de modul în care obiectele se pot accesa unele pe
altele.

multiplicitate 1 nume_asociere multiplicitate 2

Clasa 1 Clasa 2
nume_rol 1 nume_rol 2

1..* detine 0..*

Persoana Cladire
proprietar bun
Tipuri de asocieri
•Unare (reflexive)
✔Asocierea reflexivă este utilizată atunci când pot fi asociate obiecte din
aceeași clasă.
✔Notația rămâne aceeași, cu excepția faptului că linia de asociere este
trasă către și din aceeași clasă.

• Binare (între două clase)

• N-are (între trei sau mai multe clase) – apar atunci când mai mult de două
obiecte sunt implicate într-o relație.
Asocieri n-are -1
•O asociere n-ară este reprezentată ca un romb gol în centru. Rombul este conectat cu
toate clasele participante prin intermediul unei asocieri nedirecționate.
•Nu există direcții de navigare pentru asocierile n-are; Se pot specifica multiplicități și
nume de roluri.

Varianta 1: Modelarea unei asocieri ternare care arată relația dintre

Student, Examen și Profesor.
✔Un Student susține un Examen fără Profesor (nu susține deloc acest
examen) sau cu exact un Profesor.
✔Un Examen cu un Profesor poate poate fi susținut de orice număr
de Studenți.
✔Un Student poate fi notat de un Profesor pentru orice număr de
Examene.
✔Nu este posibil ca doi sau mai mulți Profesori să noteze un Student
pentru același Examen.
Asocieri n-are -2
Varianta 2: Transformarea asocierii ternare în ouă asocieri binare va
conduce la un model cu o semnificație diferită.
✔Un examen poate fi notat de mai mulți profesori.
✔Nu se arată în mode clar ce Profesor a evaluat un anumit Student la
Examen.
✔Varianta 1: studentul s1 a susținut examenul e1 cu profesor p1 și
că studentul s2 a susținut același examen e1 cu profesor p2.
✔Varianta 2: se poate exprima doar că studenții s1 și s2 au susținut
examenul e1 și că examenul e1 are doi examinatori p1 și p2. Cu
acest model, nu puteți exprima ce profesor notează pe ce student.

Varianta 3: Poate fi introdusă o clasă suplimentară pentru

notare.
✔În acest model este posibil ca un student să fie notat de
mai multe ori pentru același examen ceea ce nu este posibil
la modelul cu asociere ternară.
Clasă modelată ca asociere
•O clasă modelată ca o asociere este utilizată pentru a surprinde anumite caracteristici ale
unei asocieri între două clase.
•Aceste caracteristici nu aparțin claselor asociate, ci aparțin relației dintre clase.
•Clasele modelate ca asocieri au sens numai dacă reprezintă asocieri cu un anumit
comportament și stare.
•Fiecărei instanțe a unei clase modelată ca asociere ar trebui să îi corespundă o pereche unică
de obiecte ale claselor care participă la asociere.
•Necesară atunci când modelăm asocieri mulți-la-mulți.
Relația de agregare
2. Agregarea este o formă de asociere binară reprezentând o relaţie de tip parte/întreg.
✔Relația de asociere indică o relație relativ slabă între două clase. Această relație “liberă”
înseamnă că obiectele aparținând acestor clase asociate pot exista independent unul de
celălalt.
✔Dacă relația dintre două clase asociate este strânsă, atunci aceasta este reprezentată de
agregare. Agregarea este astfel o formă specială de asociere.
✔Agregarea reprezintă o clasă care conține o altă clasă
✔Are semnificații precum: “Este format din”, “Conține” ,“Are”.
✔Există două forme ale relației de agregare:
▪ Agregare partajată
▪ Agregare compusă
Agregarea partajată
• Agregarea partajată este o formă slabă de agregare în care instanţele părţilor sunt
independente de întreg, astfel:
✔Aceleaşi părţi partajate pot fi incluse în mai multe clase întreg.
✔Dacă clasa întreg se şterge, clasele parte vor exista în continuare.
✔Se reprezintă sub forma unui romb gol plasat la capătul clasei întreg.

Laborator conține Calculator.

Biblioteca are Exemplar Carte
Este o relație mai strânsă.
Agregarea compusă
• Agregarea compusă este o formă puternică de agregare în care instanţele părţilor sunt
independente de întreg, astfel:
✔Dacă clasa întreg se şterge, clasele parte vor vor fi şterse şi ele.
✔Se reprezintă sub forma unui romb plin plasat la capătul clasei întreg.
✔Atunci când se foloseşte pentru modelarea obiectelor dintr-un anumit domeniu,
ştergerea poate fi interpretată la figurativ, ca “terminare”, şi nu ca o distrugere fizică.
Legătura între asociere, agregare şi compunere

Asociere
Obiectele ştiu unele de existaţa celorlalte şi pot lucra împreună.

Agregare
1. Protejează integritatea configuraţiei.
2. Funcţionează ca un tot unitar.
3. Control prin intermediul unui singur obiect.

Compunere
Fiecare parte poate fi membră a unui singur obiect agregat.
Relația de generalizare -1
• Căutarea elementelor comune în cadrul atributelor și operațiilor unui grup de clase și
plasarea acestora într-o clasă comună sau generică se numește generalizare.
• Deplasarea în sus a ierarhiei moștenirii necesită cunoașterea domeniului și gândirea
abstractă.
• Când clasele sunt derivate pe baza claselor existente în clase specializate, se numește
specializare.
• Specializarea necesită o gândire concretă - deplasarea spre implementare.
Relația de generalizare -2
• Aceste clase de nivel superior-inferior sunt, de asemenea, cunoscute sub numele de
super-sub, părinte-copil sau clase derivate- de bază. Frecvent, super-clasele sunt clase
abstracte.
• Se mai numeşte informal şi relaţie de genul “este un tip de” sau “este un”.
• Se reprezintă sub forma unui triunghi gol plasat la capătul superclasei.
• Este permisă moștenirea multiplă.
Sugestii pentru denumirea claselor
✔Numele clasei este reprezentat de un substantiv la singular.

✔Numele claselor încep cu literă mare.

✔Numele claselor abstracte este scris cu italic.

✔Pot exista și clase al căror nume este compus din două sau mai multe cuvinte
(exemplu: PacientPrivat).

✔Stereotipul unei clase apare ori sub formă de pictogramă specifică, ori având
denumirea scrisă deasupra numelui clasei între simbolurile << >>.
Bune practici – Multiplicități
✔Multiplicitățile indică numărul de obiecte ale unei clase legate de un obiect al altei
clase.

✔Multiplicitățile au sens atunci când două clase sunt în asociere sau agregare.

✔Multiplicitățile indică, de asemenea, reguli ale afacerii.

✔Rețineți că NU pot exista multiplicități între două clase care au o relație de

moștenire.

✔În cazul agregării, o multiplicitate în clasa de nivel superior (clasa întreg), deși nu este
greșită din punct de vedere sintactic, are o semnificație semantică limitată.
Multiplicitatea corespunzătoare clasei întregi este unu.
Aprofundăm- 1
Cum modelați următoarea situație într-o diagramă de clase UML:
O comandă este plasată cu ajutorul unui chelner, un chelner se ocupă de mai multe comenzi.

Variante:
a) 1+2
b) 1+3
c) 1+4
d) 2+3
Aprofundăm- 2
Pornind de la diagrama din imagine, care dintre următoarele afirmații este adevărată?

1. Un obiect al clasei A poate avea asociat un obiect al clasei B

2. Dacă o instanță a lui B este ștearsă, atunci sunt șterse și toate instanțele lui A
3. Rombul de lângă A poartă numele de compunere
4. Un obiect al lui B este inclus într-un sigur un obiect al lui A
Variante:
a) 1+4
b) 1+3
c) 2+3
d) 3+4
Aprofundăm- 3
O relație de generalizare între o subclasă și o superclasă are următoarele proprietăți:
1.subclasa moștenește proprietățile superclasei
2.subclasă poate moșteni de la o singură superclasă
3.subclasa nu poate avea mai multe atribute și operații decât superclasa
4.superclasa nu poate să fie abstractă

Variante:
a) 1
b) 1+2
c) 1+2+3
d) 1+2+3+4
Aprofundăm- 4
În această reprezentare a unei clase identificați:
• Numele clasei
• Stereotipul
• Atributele
• Valoarea inițială
• Vizibilitatea atributelor
• Tipul atributelor
• Operațiile
• Vizibilitatea operațiilor
• Valoarea returnată
Studiu de caz
Scopul proiectului este realizarea unui sistem informatic pentru gestiunea activităților de rezervare și
cazare ale unei unități hoteliere. În vederea cazării, un client poate solicita rezervarea uneia sau mai multor
camere prin e-mail, telefonic sau folosind site-uri specializate în rezervări hoteliere. Pentru rezervările prin
email sau telefonic, clientul furnizează recepționerului informații privind perioada de cazare și tipurile de
camere solicitate. Clienții vor beneficia de reduceri implicite dacă rezervă cel un număr minim de camere
sau dacă perioada de cazare depășește patru zile. Recepționerul verifică disponibilitatea camerelor și îl
înștiințează pe client de acest lucru precum și de costul estimat al cazării. Dacă nu există camere disponibile
conform solicitării, recepționerul poate oferi clientului alternative. De asemenea, clientul poate solicita un
discount suplimentar, iar recepționerul va decide fezabilitatea discountului, fiind asistat obligatoriu de
managerul hotelului. În situația în care clientul este de acord cu prețul propus, se va proceda la realizarea
rezervării. Pentru clienții noi, recepționerul solicită datele de identificare, pe care le introduce în aplicație.
Nu se poate acorda discount suplimentar pentru rezervările făcute prin intermediul site-urilor specializate.
Odată ajuns la hotel, și dacă a făcut în prealabil o rezervare, clientul va furniza datele de identificare ale sale
și/sau ale rezervării și se face cazarea. Dacă nu există o rezervare, se va verifica disponibilitatea camerelor
pentru perioada cerută. Atunci când se găsește o astfel de cameră, se face cazarea. La finalul sejurului,
recepționerul întocmește o listă cu toate serviciile solicitate de client, precum și prețul acestora. Lista
trebuie validată de client, după care se întocmește factura finală. Factura poate fi plătită parțial sau
integral, prin transfer bancar, numerar sau folosind un card bancar. Totodată, înainte de a părăsi hotelul,
clientul este rugat să completeze un formular prin care să evalueze serviciile oferite de unitatea hotelieră.
După eliberarea camerei, camerista verifică starea acesteia și informează recepția.
⮚Să se reprezinte în Visual Paradigm diagrama de clase pentru scenariul de mai sus.
De lucru
Realizați diagrame de clase pentru situațiile de mai jos:
1. O echipă este formată din 11 jucători, dintre care unul este căpitan.
2. O companie este formată din departamente. Departamentele sunt localizate în una sau mai
multe clădiri de birouri. Unul dintre birouri funcționează ca sediu central. Fiecare
departament care un manager care este recrutat din rândul angajaților săi.
3. Un colecționar deține una sau mai multe colecții. Pentru a se constitui o colecție sunt
necesare cel puțin 2 obiecte.
4. Într-o clinică medicală, un pacient care prezintă anumite simptome, poate realiza programări
la medicii clinicii. Atât medicii cât și pacienții trebuie să fie utilizatori ai sistemului.
Proiectarea sistemelor
informatice
Seminar 3 - Limbajul UML
Diagrama cazurilor de utilizare
 Nume diagramă Scop Etape specifice

Diagrame structurale
Clase Ilustrează relațiile dintre clasele modelate în cadrul Analiză, Proiectare
sistemului.
Obiecte Ilustrează relațiile dintre obiectele modelate în sistem, Analiză, Proiectare
atunci când instanțe ale claselor identificate comunică
mai bine modelul construit.
Pachete Grupează împreună alte elemente ale UML pentru a Analiză, Proiectare,
forma construcții de nivel înalt. Implementare
Desfășurare Descrie arhitectura fizică a sistemului. Poate fi folosită Proiectare fizică,
și pentru a reprezenta componentele software care se Implementare
suprapun peste arhitecrura fizică.
Componente Ilustrează relațiile fizice dintre componentele software. Proiectare fizică,
Implementare
Tipuri de diagrame Structură compusă Descrie structura internă a unei clase, cum ar fi relațiile Analiză, Proiectare
dintre părțile unei clase.
Este folosită pentru a construi extensii ale limbajului Niciuna
UML Profile
UML.
Diagrame comportamentale
Cazuri de utilizare Identifică cerințele sistemului pentru a ilustra Analiză
interacțiunile dintre sistem și mediul său.
Activitate Ilustrează fluxurile de lucru independente ale unei clase, Analiză, Proiectare
fluxul de activități dintr-un caz de utilizare sau
proiectarea detaliată a unei metode.
Secvență Modelează comportamentul obiectelor în cadrul unui caz Analiză, Proiectare
de utilizare cu accent pe ordinea temporală a
activităților.
Comunicare Modelează comportamentul obiectelor în cadrul unui caz Analiză, Proiectare
de utilizare cu accent pe comunicarea între obiectele
care colaborează într-o activitate.
Interacțiuni de ansamblu Ilustrează ordinea fluxurilor de control ale unui proces. Analiză, Proiectare
Timp Arată interacțiunea în cadrul unei mulțimi de obiecte și Analiză, Proiectare
ale schimbărilor de stări prin care trec acestea de-a
lungul axei timpului.
Mașini de stări Examinează comportamentul unei clase. Analiză, Proiectare
Diagramele UML în ciclul de dezvoltare

Anumite diagrame pot juca un rol mai important în funcție de etapa de dezvoltare a sistemului

Același tip de diagramă poate fi folosit pe parcursul ciclului de dezvoltare

❑ Se pleacă inițial de la aspecte conceptuale și abstracte

❑ Diagramele evoluează și includ detalii care în final vor sta la baza generării sau scrierii de cod

Diagramele vor face trecerea de la documentarea cerințelor la stabilirea detaliilor de proiectare

Relațiile dintre diagramele UML permit crearea de modele consistente

Sunt acoperitoare pentru majoritatea aspectelor care descriu un sistem

 Reprezintă grafic funcţionalitǎţile pe care trebuie
sǎ le îndeplineascǎ sistemul informatic

Diagrama cazurilor Împreună cu descrierea textuală a fiecǎrui caz de

utilizare poartǎ numele de model al cerinţelor
de utilizare

Sunt formate din actori şi cazuri de utilizare,

împreună cu relaţiile dintre acestea
Actori - 1
• Sunt persoane sau sisteme informatice care interacţioneazǎ cu
sistemul informatic dezvoltat.
• Actorii reprezintă roluri care pot include factori umani, hardware
extern sau alte sisteme.
• O persoanǎ poate juca mai multe roluri şi un rol poate caracteriza mai
multe persoane.
• Un actor principal este un beneficiar direct al funcționalităților oferite
de sistem, iar un actor secundar are rolul de a oferi servicii sistemului.
Actori - 2
• Determinarea actorilor se face rǎspunzând la întrebǎri precum:
✓ Cine solicită date din sistem?
✓ Cine modificǎ date din sistem?
✓ Cine este interfaţă cu sistemul?
✓ Cine interacţionează cu sistemul?
• Se reprezintă folosind simbolul specific al unui omuleţ stilizat având la
subsol un text ce explicǎ rolul jucat de actor.
Cazuri de utilizare - 1
• Modeleazǎ un dialog între un actor şi sistemul informatic.
• Această interacțiune este menită să ofere actorului rezultate concrete
și măsurabile.
• Sunt orientate pe scop: arată ceea ce sistemul trebuie sǎ facǎ, şi nu
cum.
• Sunt înrudite din punct de vedere comportamental.
• Numele unui caz de utilizare desemnează o acțiune și trebuie să
includă un verb.
Cazuri de utilizare - 2
• Sunt neutre din punct de vedere tehnologic, putând fi utilizate în orice
proces sau arhitecturǎ de aplicaţie.
• Mulţimea de cazuri de utilizare a unui sistem reprezintǎ toate
modalitǎţile în care sistemul poate fi folosit.
• Reprezentarea graficǎ se realizeazǎ prin intermediul unui oval, având
numele cazului de utilizare notat la bază sau în interior.
Relații între actori și cazuri de utilizare -1
• Diagrama cazurilor de utilizare cuprinde relaţiile dintre
un set de cazuri de utilizare şi actorii care participă la
realizarea acestor cazuri de utilizare.
• Sunt folosite asocierile simple pentru a conecta un actor
cu un caz de utilizare.
• Aceasta reprezintă o cale de comunicare între cei doi.
• NU are rolul de a descrie fluxuri de activități.
• Se pot delimita graniţele sistemului analizat prin
includerea cazurilor de utilizare în interiorul unui
dreptunghi.
Relații între actori și cazuri de utilizare - 2
• La acest nivel sunt permise și multiplicităţile Dacă multiplicitatea mai
mare decât unu la capătul:
▪ corespunzător cazului de utilizare, atunci actorul este implicat în mai multe cazuri de utilizare
de acel tip şi poate iniţia cazuri de utilizare: în paralel (concurent), la diferite momente de timp
sau mutual exclusiv în timp. De remarcat că UML nu are notaţii standard pentru situaţiile de mai
sus.
▪ corespunzător actorului, atunci mai multe instanţe ale actorului sunt implicate în iniţierea
cazului de utilizare putând realiza acţiuni simultane sau succesive.
Relații între actori
• Sunt de tipul generalizare/specializare, între un actor părinte şi unul
sau mai mulţi actori copii.
• Se pot defini actori abstracți (actorul “Utilizator”).
• Actorul copil moștenește proprietățile actorului părinte.
 Între două cazuri de utilizare care se referă la
acelaşi sistem nu pot exista relaţii simple.

Relații între cazurile Fiecare caz de utilizare descrie un mod de utilizare

complet al sistemului.
de utilizare

Între cazurile de utilizare pot exista trei tipuri de

relații calificate: includere, extindere și generalizare.
 <<include>>
Relația de includere
• Are ca scop integrarea unui caz de utilizare în alt caz de
utilizare, primul devenind astfel o parte logică din acel caz
de utilizare.
• Cazul de utilizare care îl include pe un altul nu este
complet.
• Se foloseşte atunci când există părţi de comportament
comune în mai multe cazuri de utilizare.
• Este echivalentă cu apelul unei subrutine în programare
și denotă un comportament obligatoriu, nu opţional.
• Nu se moştenesc proprietăţi de la un caz de utilizare la
altul, scopul este acela de a evita redundanţa părţilor ce
au comportament identic.
 <<extend>>
Relația de extindere
• Descrie un comportament care are loc doar în anumite condiţii, ce pot fi selectate pe
baza alegerii unui actor.
• Cazul de utilizare extins este complet şi independent de cel care îl extinde.
• Extinderea are loc în unul sau mai multe puncte de extindere, definite în cazul de utilizare
extins.
• Se pot asocia note sau constrângeri pe această relaţie pentru a ilustra condiţiile în care
comportamentul extins trebuie executat.
Relația de generalizare
• Se foloseşte când există două sau mai multe cazuri de utilizare care au în comun
comportament, structură şi scop.
• Comportamentul cazului de utilizare părinte poate fi suprascris.
• Se specifică numai diferenţele dintre cele două în cazul de utilizare specializat.
Descrierea textuală a cazurilor de utilizare
Element al cazului Descriere
• Toate procesele care trebuie de utilizare
executate de sistem se regăsesc Cod Un identificator unic asociat cazului de utilizare
Stare Stadiul de finalizare în care se găseşte, de exemplu: schiţă,
într-un caz de utilizare. finalizat sau aprobat
• Cazurile de utilizare sunt Scop
Nume
Sistemul (parte a sistemului) sau aplicaţia căreia îi aparţine
Numele cazului de utilizare, cât mai scurt şi reprezentativ
descrise apoi textual sau printr-o Actor principal Beneficiarul care iniţiază cazul de utilizare şi care urmăreşte
succesiune de paşi. un anumit scop
Descriere Prezentare scurtă, in text liber, a cazului de utilizare
• Pentru modelarea grafică a Precondiţii Ce condiţii trebuie satisfăcute pentru ca scenariul să poată
începe
scenariilor poate fi utilizată Postcondiţii Ce condiţii trebuie îndeplinite pentru a garanta un final reuşit
diagrama de activitate. al scenariului
Declanşator Un eveniment sau o succesiune de evenimente care iniţiază
• Se pot folosi șabloane pentru a cazul de utilizare
structura descrierea unui caz de Flux de bază Fluxul de bază descrie înşiruirea evenimentelor atunci când
totul se petrece conform unui scenariu prestabilit; nu există
utilizare. excepţii sau erori
Fluxuri alternative Cele mai semnificative alternative şi excepţii ale scenariului
de bază
Relaţii Ce relaţii are cu alte cazuri de utilizare (de tipul include sau
extends)
Frecvenţa utilizării Cât de des se estimează că va fi folosită această
funcţionalitate a sistemului
Reguli ale afaceri Ce reguli guvernează cazul de utilizare; ce prerogative trebuie
să aibă actorii
Bune practici - Actori
✓ Dați nume relevante actorilor – În situația în care sistemul interacționează cu o
organizație externă, specificați tipul de organizație, mai degrabă decât numele acesteia.
(De exemplu: Companie aeriană este o alegere mai bună decât BlueAir)

✓ Actorii principali ar trebui să fie plasați în partea stângă a diagramei - Acest lucru
vă permite să evidențiați rapid rolurile importante din sistem.

✓ Sistemele externe sunt actori - Dacă un caz de utilizare “Trimitere prin e-mail”
interacționează cu software-ul de gestionare a e-mailului, atunci software-ul respectiv este
un actor.

✓ Actorii nu interacționează cu alți actori - În cazul în care actorii interacționează într-

un sistem, trebuie creată o nouă diagramă de cazuri de utilizare cu sistemul din diagrama
anterioară reprezentat ca actor.

✓ Plasați actorii copii sub actorul părinte - Acest lucru pentru a crește lizibilitatea și
evidențiază rapid cazurile de utilizare specifice acelui actor.
Bune practici – Cazuri de utilizare
✓ Numele încep cu un verb - Un caz de utilizare modelează o acțiune, astfel încât
numele trebuie să înceapă cu un verb.

✓ Atribuiți un nume descriptiv - Aceasta este pentru a oferi mai multe informații pentru
cei care citesc și validează diagrama. De exemplu, „Printează factură” este mai bun decât
„Printează”.

✓ Evidențiați ordinea logică - De exemplu, într-o aplicație bancară este preferabil să

plasăm cazurile de utilizare într-o ordine de genul, „Deschide cont”, „Depune bani” și
„Retrage bani”. Arătarea lor în ordinea logică are mai mult sens.

✓ Plasați cazurile de utilizare incluse în partea dreaptă a cazului de utilizare care

include - Acest lucru îmbunătățește lizibilitatea și adăugă claritate.

✓ Plasați cazul de utilizare copil sub cazul de utilizare părinte - Din nou, acest lucru
se face pentru a îmbunătăți lizibilitatea diagramei.
Bune practici – Relații
✓ Săgeata arată spre cazul de utilizare de bază atunci când utilizați <<extend>>.

✓ Relația <<extend>> poate avea condiții de extensie opționale.

✓ Săgeata arată spre cazul de utilizare inclus atunci când utilizați <<include>>.

✓ Atât <<extend>>, cât și <<include>> sunt afișate ca săgeți cu linii întrerupte.

✓ Relația dintre actor și caz de utilizare nu are săgeți, este o asociere reprezentată ca
linie continuă.

✓ Între doua cazuri de utilizare nu pot exista relații de asociere (linii simple). Acestea
întotdeauna calificate și pot fi de tipul <<extend>>, <<include>> sau generalizare.
Bune practici – Exemple
Aprofundăm - 1
Cum modelați următoarea situație într-o diagramă UML de cazuri de utilizare:
Un mecanic efectuează verificarea unui mașini. În timpul acelei verificări, poate fi
necesară schimbarea unei piese.

A) B)

C) D)
Aprofundăm - 2
Care dintre următoarele cazuri de utilizare este un caz de utilizare corect dacă vrem să
realizăm o diagramă de cazuri de utilizare pentru un magazin online de cărți?
1. Caută o carte
2. Comandă o carte
3. Nu comandă o carte
4. Anulează o comandă
5. Login
6. Introduce nume carte
Variante de răspuns:
A) 1+2+3+6
B) 1+2+3+4
C) 1+2+4
D) 1+3+4+5
Aprofundăm - 3
Identificați exemplul greșit din figurile de mai jos.

A) B)

C) D)
Aprofundăm - 4
Ce tip de relație este potrivită pentru cazurile de utilizare din figură?

Variante de răspuns:

A) Includere
B) Asociere
C) Generalizare
D) Extindere
Studiu de caz
Scopul proiectului este realizarea unui sistem informatic pentru gestiunea activităților de rezervare și
cazare ale unei unități hoteliere. În vederea cazării, un client poate solicita rezervarea uneia sau mai multor
camere prin e-mail, telefonic sau folosind site-uri specializate în rezervări hoteliere. Pentru rezervările prin
email sau telefonic, clientul furnizează recepționerului informații privind perioada de cazare și tipurile de
camere solicitate. Clienții vor beneficia de reduceri implicite dacă rezervă cel un număr minim de camere
sau dacă perioada de cazare depășește patru zile. Recepționerul verifică disponibilitatea camerelor și îl
înștiințează pe client de acest lucru precum și de costul estimat al cazării. Dacă nu există camere disponibile
conform solicitării, recepționerul poate oferi clientului alternative. De asemenea, clientul poate solicita un
discount suplimentar, iar recepționerul va decide fezabilitatea discountului, fiind asistat obligatoriu de
managerul hotelului. În situația în care clientul este de acord cu prețul propus, se va proceda la realizarea
rezervării. Pentru clienții noi, recepționerul solicită datele de identificare, pe care le introduce în aplicație.
Nu se poate acorda discount suplimentar pentru rezervările făcute prin intermediul site-urilor specializate.
Odată ajuns la hotel, și dacă a făcut în prealabil o rezervare, clientul va furniza datele de identificare ale sale
și/sau ale rezervării și se face cazarea. Dacă nu există o rezervare, se va verifica disponibilitatea camerelor
pentru perioada cerută. Atunci când se găsește o astfel de cameră, se face cazarea. La finalul sejurului,
recepționerul întocmește o listă cu toate serviciile solicitate de client, precum și prețul acestora. Lista
trebuie validată de client, după care se întocmește factura finală. Factura poate fi plătită parțial sau
integral, prin transfer bancar, numerar sau folosind un card bancar. Totodată, înainte de a părăsi hotelul,
clientul este rugat să completeze un formular prin care să evalueze serviciile oferite de unitatea hotelieră.
La eliberarea camerei, camerista verifică starea acesteia și informează recepția.
➢ Să se reprezinte în Visual Paradigm diagrama de cazuri de utilizare pentru scenariul de mai sus.
 Studiu individual

Comerț Învățământ Servicii

electronic universitar medicale

Realizați o diagramă de cazuri de utilizare pentru una dintre cele trei categorii de sisteme
Proiectarea sistemelor
informatice
Seminar 2
Cuprins

01 02
Identificarea cerințelor Analiza cerințelor
textuale

03
Structurarea cerințelor -
tabele de decizie
 Reprezintă procesul prin care culegem și documentăm cerințele
sistemului.

Cu cât descoperim mai multe cerințe, cu atât va fi mai bun

sistemul construit.

Identificarea Cerințele se schimbă.

cerințelor
Pot exista cerințe care sunt deja implementate.

Cerințele pot fi: a) explicite – furnizate de beneficiar

b) implicite – le descoperă analistul.
Surse pentru identificarea cerințelor

Beneficiar Artefacte
Interviuri Documente de intrare
Ședințe comune Rapoarte de ieșire
Legislație
Observații directe ....
Prototipizare
Artefacte
•Artefactele conțin orice informații existente despre sistem care pot fi culese din
diverse surse:
✔Documente preexistente despre funcționarea sistemului
✔Eșantioane de date
✔Chestionare
✔Scenarii
✔Prototipuri de interfețe
✔Scheme conceptuale
✔......
•În primul rând trebuie înțeleasă organizația, chiar și la nivel de bază:
✔Cu ce se ocupă
✔Care sunt fluxurile de lucru
✔Ce politici a adoptat
✔Cine sunt beneficiarii sistemului
 Cerințele se schimbă

Necesitatea Obținem feedback în mod

frecvent
implicării active a
beneficiarului Rezolvăm aspecte
neînțelese

Încercăm să eliminăm ambiguități

Bune practici
✔Evită jargonul tehnic
✔Încearcă să înțelegi vocabularul afacerii
✔Fii respectuos
✔Ia în considerare faptul că persoana cu care
discuți poate nu știe să îți răspundă la toate
întrebările
✔Explică tipurile de documente/modelele care se
vor crea pe baza cerințelor și care trebuie validate de
client
✔ Oferă idei și alternative
✔Verifică, pe cât posibil, informațiile culese
✔Atunci când cerințele se modifică, informează
clientul cât mai corect referitor la costurile acestor
schimbări
 Analiza cerințelor textuale -1
cu aplicații în
ABCTV este o companie care oferă servicii de transmisie TV online. Aceasta intenționează să își
perfecționeze serviciile prin restructurarea sistemului său informatic.
Vom folosi analiza textuală pentru a identifica principalele cazuri de utilizare ale sistemului și pentru a
crea o diagramă de cazuri de utilizare.
1. Descărcați fișierul ABCTV.txt din materialele disponibile pentru seminar. Acesta conține o descriere
generală a principalelor cerințe ale sistemului.
2. Deschideți Visual Paradigm Enterprise Edition
3. Creați un nou proiect selectând Project > New din bara de meniu a aplicației. În fereastra New
Project introduceți ABCTV ca nume al proiectului și apoi selectați Create Blank Project.
4. Selectați Diagram > New din bara de meniu.
5. În fereastra New Diagram, selectați Textual Analysis și apăsați Next.
6. Apăsați OK pentru a crea o descriere a cerințelor sistemului.
7. Cerințele se pot introduce direct prin intermediul unui editor sau se pot importa dintr-un fișier existent.
În acest caz vom importa cerințele, apăsând butonul Import File ( ), selectând fișierul ABCTV.txt și
apoi Open.
8. Textul a fost importat. Studiați descrierea cerințelor.
 Analiza cerințelor textuale - 2
9. Identificați toți actorii implicați în utilizarea sistemului. Actorii (concept al diagramei de cazuri de
utilizare din limbajul UML) reprezintă diferite categorii de utilizatori ai sistemului sau alte sisteme cu care
acesta interacționează pentru implementarea funcționalităților. Parcurgând descrierea cerințelor, putem
identifica primul actor candidat, membru general, în cel de-al doilea paragraf. Selectați textul “membru
general”, faceți click dreapta și selectați din lista Add text as opțiunea Actor din meniul care apare.
 Analiza cerințelor textuale - 3
10. Verificați grila din partea de jos a ferestrei. Acesta listează proprietățile obiectului candidat extras:
Candidate Class (numele obiectului candidat), Extracted Text (cuvânt / expresie din care a fost
extras), Type (tip candidat), Description, Occurrence (de câte ori cuvântul / expresia apare în cerințele
textuale) și Highlight (culoarea de evidențiere a obiectului candidat).

11. În mod similar, identificați și ceilalți doi actori candidați, “membru premium” și “administratorii”.
Schimbați numele ultimului actor candidat în “administrator”.

12. Identificați cazurile de utilizare candidate. Cazurile de utilizare descriu modul în care utilizatorii
folosesc sistemul. De obicei, cazurile de utilizare candidate sunt denumite prin intermediul unui verb sau
al unei expresii verbale (spre exemplu, verb + substantiv). Selectați textul “se inregistreaza gratuit ca
membru general”, faceți click dreapta și selectați opțiunea Use Case. Schimbați denumirea (câmpul
Candidate Class) în “se inregistreaza ca membru general”.
 Analiza cerințelor textuale - 4
13. În mod similar, evidențiați următoarele secvențe de text pentru a le identifica drept cazuri de utilizare
candidate:
- a viziona orice programe TV arhivate
- se inregistreaza ca membru premium
- sa vizioneze atat programe arhivate, cat si programe live
- sa devina membru premium
- sa revina la statutul de membru general
- elimine contul permanent
- posteaza opiniile
- primesc un buletin informativ lunar
- actualizeaza grile de programe
- actualizeaza continutul unui program
- arhiveaza programele
- monitorizeaza transmiterea newsletter-ului
 Analiza cerințelor textuale - 5
14. Pentru a face distincție între obiectele candidate din descrierea cerințelor, se poate modifica
culoarea de fundal. Vom modifica in portocaliu culoarea de fundal pentru actori.

15. Dacă este necesar, modificăm numele actorilor și ale cazurilor de utilizare, astfel încât acestea să
fie scurte, informative și intuitive. În tabelul de mai jos sunt specificate denumirile claselor candidate,
după rafinarea textului extras, împreună cu o descriere succintă a acestora. Redenumiți clasele
candidate și completați descrierile conform umătorului tabel.
Tabel clase candidate - 1
Tabel clase candidate - 2
 Analiza cerințelor textuale - 6
16. Analiza textuală în Visual Paradigm produce următoarele rezultate:
 Analiza cerințelor textuale - 8
17. Schimbăm panoul de vizualizare apăsând butonul Candidate Pane View. În acest panou se pot
vizualiza obiectele candidate în scopul unei aranjări facile.

18. Vom crea o diagramă de cazuri de utilizare pornind de la aceste obiecte candidate.
Selectăm Diagram > New din bara de meniu. În fereastra New Diagram , selectați Use Case
Diagram și apoi Next. Apăsați OK pentru a crea diagrama.
19. Deschideți tab-ul Model Explorer din partea dreaptă a ferestrei sau Apăsați View > Panes > Model
Explorer din bara de meniu.
20. Selectați toți actorii și cazurile de utilizare și, cu drag&drop plasați-le pe suprafața goală din partea
dreaptă.
 Analiza cerințelor textuale - 9
21. Rearanjați obiectele de pe diagramă și asociați actorii cu cazurile de utilizare prin linii simple
(Association pe bara de instrumente din partea stângă).
 Structurarea cerințelor cu ajutorul tabelelor de decizie

Tabele de decizie

Modalitate de reprezentare grafică ce ajută, în Se folosesc cu precădere în domenii de activitate

cadrul unui proces complex, la vizualizarea și unde se întâlnesc un număr semnificativ de reguli
înțelegerea diferitelor acțiuni care sunt întreprinse de afaceri pe baza cărora se iau decizii. Exemple:
pentru o varietate de condiții. asigurările, telecomunicații (stabilirea de planuri
tarifare), bancar (calcularea scoringului).

Sunt utilizate pentru procese complexe în programare,

în testarea de software, dar sunt în mod frecvent
percepute ca metode pentru specificarea de politici și
seturi de reguli pe care oamenii trebuie să le respecte.
Studiu de caz - tabele de decizie

Compania ABCTV are o serie de reguli ce prezintă politica salarială a diferitelor tipuri de angajați.
Regula 1: Dacă un angajat este salariat cu normă întreagă, indiferent câte ore a lucrat, întotdeauna
va fi plătit cu salariul de bază.
Regula 2: Dacă un angajat are contract de colaborare și lucrează mai puțin de 40 de ore, atunci va
fi plătit cu salariul orar și se va realiza un raport de absență pentru acest angajat.
Regula 3: Dacă un angajat are contract de colaborare și lucrează exact de 40 de ore, atunci va fi
plătit cu salariul orar.
Regula 4: Dacă un angajat are contract de colaborare și lucrează mai mult de 40 de ore, atunci va fi
plătit cu salariul orar și i se vor plăti și orele suplimentare.
Tabele de decizie la nivel conceptual - 1

Tabela de decizie are două dimensiuni:

✔o dimensiune este formată din mulțimea de condițiilor și mulțimea acțiunilor posibile

✔o altă dimensiune reprezintă combinațiile dintre condiții și acțiuni, care duc la formarea de reguli

Regula 1 Regula 2 Regula 3 Regula 4

DACĂ Condiție 1 Y Y N N

ȘI Condiție 2 Y N Y Y

ȘI Condiție 3 - N Y -

ȘI Condiție 4 - - Y N

ATUNCI

ȘI Acțiune 1 X X

ȘI Acțiune 2 X X X

ȘI Acțiune 3 X
Tabele de decizie la nivel conceptual - 2
Pasul 1: Identificarea condițiilor politicii salariale
Se pot identifica două condiții: tipul de angajat și numărul de ore lucrate.
Pasul 2 – Identificarea alternativelor condițiilor
Alternativele condițiilor reprezintă mulțimea de valori posibile pentru fiecare condiție. De
asemenea, sunt combinate în toate variantele posibile. Condiția „tip angajat” are două
valori: N (normă întreagă) sau C (contract de colaborare). Condiția „ore lucrate” are 3 valori
posibile: orele sunt mai mari de 40, orele sunt egale cu 40 și orele sunt mai mici de 40. O
alternativă de notație pentru o condiție o reprezintă simbolul liniuță (-), arătând că valorile
pentru această condiție sunt irelevante.
Pasul 3 – Identificarea acțiunilor
Sub condiții, sunt enumerate acțiunile. În acest exemplu, există patru acțiuni posibile:
1. Plătește angajatului salariul de bază
2. Plătește angajatului salariul pe oră
3. Plătește angajatului ore suplimentare
4. Realizează un raport de absență
Tabele de decizie la nivel conceptual - 3
Pasul 4 – Stabilirea posibilităților de realizare a acțiunilor
Lângă lista acțiunilor, se specifică dacă acțiunile pot fi realizate în condițiile respective. Se va
indica folosind simbolul X dacă acțiunile trebuie efectuate, având în vedere un anumit set
de valori ale condițiilor. Unele seturi de condiții pot avea asociate mai multe acțiuni, cum
este cazul cu Regula 4.
Pasul 5 – Validarea regulilor
Regulile sunt coloanele numerotate din tabel. Pentru a citi un tabel, localizați regula
aplicabilă găsind coloana care corespunde unui criteriu dat pentru condiții.
Studiu de caz - 1
Vom crea În Visual Paradigm o tabelă de decizie care reprezintă cele patru reguli care
definesc politica de salarizare.
1. În Visual Paradigm Enterprise Edition folosiți proiectul creat anterior în acest seminar.
2. Pentru a crea o tabelă de decizie, selectați Diagram > New din bare de meniu. În
fereastra New Diagram , selectați Decision Table și apoi Next. Păstrați opțiunea Blank și
apoi Next.
3. În Visual Paradigm condițiile pot accepta doar valori booleene (Yes/No). De aceea, vom
extinde condițiile din tabela de decizie construită la nivel conceptual, astfel:
- Condiția 1: Angajat cu norma intreaga
- Condiția 2: Angajat cu contract de colaborare
- Condiția 3: Ore lucrate < 40
- Condiția 4: Ore lucrate = 40

Se păstrează acțiunile identificate anterior.

Studiu de caz - 2
4. Adăugați condiții și acțiuni. Ca în figura de mai jos, folosind butoanele și sau apăsând
pe semnul plus (+) care apare când poziționăm mouse-ul peste textele „Conditions” și
„Actions”
Studiu de caz - 3
5. Adăugați cele patru reguli, în coloana “Rules”. Pentru fiecare regulă, făcând dublu click pe
celula corespunzătoare condiției sau acțiunii, selectați una dintre opțiunile Yes/No pentru
condițiile care formează regula și bifați acțiunile corespunzătoare X(Marked). Regulile trebuie
să fie definite conform următoarei figuri:
6. Salvați proiectul.
Proiectarea sistemelor
informatice
Seminar 1 - Introducere
Dezvoltarea de
software este un
proces complex

Implică o multitudine de elemente

care trebuie armonizate
 Ce armonizăm

Resurse umane Modele de afaceri

Beneficiari, dezvoltatori, Producție, HR, contabilitate,
specialiști în domeniu, utilizatori sănătate, învățământ

Cerințe tehnice Cerințe economice

Software, hardware, rețele Bugete, termene
Provocări
Comunicare inadecvată în cadrul echipei de dezvoltare

Planificare defectuoasă a procesului de dezvoltare software

Reticența beneficiarilor sau utilizatorilor

Testarea inadecvată a software-ului

Progresul rapid al tehnologiei

Modificarea cerințelor clienților

Limite de timp, resurse, infrastructură

 Creșterea nivelului de disciplină și rigurozitate

Etapizare, planificare, coordonare, stabilire rezultate (livrabile)

Facilitarea comunicării între membrii echipei de dezvoltare

Soluții
Folosirea de modele

Utilizarea de standarde
Ce sunt modelele?
• Simplificări sau abstractizări ale unor elemente reale sau care se
proiectează.
• Evidenţiază numai acele elemente care sunt importante pentru analist.
• Sunt specificate folosind notaţii grafice sau textuale precise, cu
ajutorul unui anumit limbaj de simboluri.
• O colecţie de imagini şi text care are o anumită semnificaţie şi
intenţionează să reprezinte ceva.
Ce sunt modelele?
• În dezvoltarea de software modelele pot fi de mai multe feluri:
• modele de mediu
• modele de domeniu
• modele de specificare a sistemului
• modele de proiectare a sistemului
• Modelele sunt valoaroase deoarece:
• sunt rapide
• sunt intuitive
• este mai simplu să modifici un model decât cod sursă
Metologii de
dezvoltare software
 Proces: un set de activităţi care concură
la atingerea obiectivelor urmărite
Metologii de
dezvoltare software Vocabular: descrie procesul şi rezultatele
obţinute în timpul aplicării acestuia

Reguli şi indicaţii: definesc calitatea

procesului şi a rezultatelor

Roluri într-o echipă de dezvoltare

 Partea unei metodologii care poate fi
standardizată este vocabularul (notaţia)

Metologii de UML (Unified Modeling Language) – notaţie

dezvoltare software comună care poate fi aplicată mai multor
metodologii

Este foarte greu să se definească un singur

proces potrivit pentru toate tipurile de
proiecte

Exemple de alte notaţii standard

Exemple de metologii
• RUP (Rational Unified Process):
• proces iterativ şi incremental
• livrarea de versiuni parţiale ale produsului la fiecare iteraţie
• perioade scurte livrare şi verificări frecvente
• rezultate verificabile pentru clienţi
• proces exhaustiv; poate deveni greu de controlat
• personalizarea RUP necesită un efort semnificativ

• OMT (Object Management Technique)

• Precursor al UML
• Utilizează conceptele orientării obiect
Exemple de metologii
• XP (Extreme Programming)
• metodologie agilă de dezvoltare
• pune accentul pe codificare (standarde, principii)
• încurajează ca programatorii să lucreze câte doi (“pair
programming”)

• numeroase sesiuni de discuţii pe parcursul dezvoltării

• fiecare iteraţie (1-4 săptămâni) are un rezultat funcţional
• suport redus pentru modelare
• relaţie strânsă între clienţi şi dezvoltatori
• lipsa documentaţiei de realizare
Ce este UML?
UML = Unified Modeling Language

Limbaj de notaţii pentru specificarea, construirea, vizualizarea şi documentarea sistemelor software

Combină cele mai bune practici în domeniul construirii diagramelor din ultimii 50 de ani

Standardizează notaţiile, dar nu stabileşte modul în care acestea să fie folosite

Nu este o metodologie, poate fi folosit ca vocabular pentru metodologii

Oferă flexibilitate dezvoltatorilor, asigurând în acelaşi timp consistenţă

Este dezvoltat şi întreţinut de Object Management Group

Istoria
UML
Diagrame
UML
Perspective asupra sistemului
Instrumente de tip CASE

• CASE = Computer Aided Software Engineering

• Necesitate:
• lucrul cu modele vizuale poate fi o activitate
dificilă şi consumatoare de timp
• nevoia unui suport informatic atunci când vrem
să menţinem integritatea modelelor
• posibilitatea de a genera cod
Instrumente de tip CASE

✓ Crearea diagramelor
✓ Gestiunea informaţiilor despre diagrame
✓ Verificarea consistenţei modelelor
✓ Crearea de legături între modele
✓ Urmărirea versiunilor modelelor
✓ Generarea de cod
✓ Inginerie directă şi inversă
 ➢ Nota de la seminar: 50% din nota finală
➢ Cerința de promovare: minim nota 5 la seminar
➢ Evaluarea la seminar presupune realizarea unui proiect
Cerințe seminar individual
PSI ➢ Proiectul implică urmărirea etapelor de specificare a
cerințelor, analiză proiectare și implementare a unui
sistem informatic
➢ Se recomandă ca tema proiectului să coincidă cu tema
de licență
➢ Evaluarea proiectului se face în 2 etape:
➢ Etapa 1 - evaluare intermediară - săptămânile 7+8
➢ Etapa 2 - evaluare finală - săptămânile 13+14
➢ Punctarea proiectului este condiționată de încărcarea la
timp și de prezentarea personală la seminar
 Studiu individual

UML OMG CASE

Investigați limbajul UML folosind resurse Investigați scopul Object Identificați un set de instrumente
Web. Prezentați în câteva paragrafe Management Group. Identificați și CASE suport pentru UML. Analizați
versiunea actuală a limbajului. alte notații pe care le gestionează. și documentați suportul oferit
www.uml.org www.omg.org. pentru construirea diagramelor.