Capitolul 5_ProiectareaProgramelor2020.ppt

Proiectarea programelor şi a procedurilor
Capitolul 5

5.1 Definirea arhitecturii programelor
Arhitectura unui program face referire la
 componentele acestuia
 proprietăţile componentelor vizibile din exterior
 relaţiile dintre componente
În cazul programelor, avem două categorii de componente:
instrucţiunile (enunţuri sau declarative)
modulele

1. funcţia
 face referire la transformările realizate asupra datelor
 este tratată în regimul cutiei negre
2. logica
 descrie prelucrările care au loc în interiorul modulului
 este tratat în regimul cutiei albe
3. interfeţele
 fac referire la structurile de date transferate între module
Proprietăţile modulelor
 arhitectura programului vizează doar funcţia şi interfeţele modulelor

 permite o mai bună comunicare între membrii echipei
 facilitează analiza aspectelor calitative ale programelor
 evidenţiază principalele decizii de proiectare care au un impact asupra
activităţilor ulterioare privind dezvoltarea programului
 facilitează repartizarea sarcinilor de lucru privind proiectarea şi scrierea
programelor pe fiecare membru al echipei
 facilitează reutilizarea componentelor atât în cazul unor sisteme similare,
cât şi în cel al reproiectării sistemului
Importanţa proiectării arhitecturii programelor

5.2 Structuri fundamentale de control a programelor
Definire - un set minim, dar necesar, de reguli prin care să se
controleze procesul de activare a componentelor de prelucrare dintr-
un program sau dintre modulele acestuia
Tipuri fundamentale de structuri
 secvenţa - parcurgerea instrucţiunilor în ordinea în care
apar
 selecţia - alegerea unui grup de instrucţiuni din două sau
mai multe posibile
 iteraţia (repetiţia) - execuţia repetată a unui grup de
instrucţiuni

Restricţii în utilizarea structurilor de control:
fiecare element (secvenţa, selecţia, iteraţia) are un punct
unic de intrare
fiecare element are un punct unic de ieşire;
elementul de iteraţie permite şi o execuţie cu factor de
repetiţie zero, adică excluderea elementului respectiv din
execuţie
Structuri fundamentale de control a programelor
(continuare)

S1
S2
Sn
Structura secvenţială (liniară)
 blocurile de instrucţiuni sunt executate în ordine
secvenţială

Selecţia sau structura alternativă (IF-THEN-ELSE)
 Dacă se îndeplineşte condiţia C, se execută operaţiile din Bloc-1,
altfel se execută operaţiile din Bloc-2
Bloc-2 Bloc-1
C
Da
Nu

Bloc-1
C
Da
Nu
Bloc-n
C
Bloc-2
Bloc-1
Variante ale structurii alternative
Structura alternativă cu o ramură vidă
Structura alternativă generalizată
(de tip CASE-OF)

Bloc-1
C
Da
Nu
Bloc-1
C
Da
Nu
Structuri de control repetitive
Structura repetitivă
condiţionată anterior
Structura repetitivă
condiţionată posterior

Bloc-1
V>Vf
Da
Nu
V:=Vi+R
V:=Vi
Structuri de control repetitive
Structura repetitivă cu număr definit de paşi (de tip DO FOR)
Numărul de repetiţii este controlat de o variabilă de control
 V este variabila de control
 Vi este valoarea iniţială a variabilei de control
 Vf este valoarea finală a variabilei de control
 R este raţia (incrementul)

Independenţa funcţională - fiecare modul de program să fie proiectat
astfel încât el să realizeze o singură funcţie sau subfuncţie a
programului
Avantajele creării de module independente constau în
 uşurinţa dezvoltării lor,
 limitarea efectelor secundare generate de modificarea codului,
 facilitarea definirii cazurilor de test,
 posibilitatea reutilizării unor module în cazul modificării
sistemului.
5.3 Evaluarea calităţii programelor
Aprecierea generală a unui soft de calitate:
 uşor de implementat
 uşor de testat
 uşor de întreţinut şi modificat

Independenţa funcţională este măsurată prin:
 Coeziune - măsura legăturilor interne dintre componentele de
prelucrare sau instrucţiuni, la nivelul unui modul
 Cuplare - măsura gradului în care modulele programelor sunt
inter-conectate
Obiectivul proiectării programelor
Gradul cuplării să fie redus iar coeziunea să fie mare
Criterii calitative ale programelor

Se poate
considera că
modulul realizează
o singură funcţie?
Sarcinile fac
parte din
aceeaşi
categorie
generală?
Da
Nu
Da
Da
Da
Nu
Nu
Nu
Atunci ce
leagă sarcinile
interne ale
modulului?
Datele
Fluxul de
control
Nici una
Secvenţa
prezintă
importanţă
?
Secvenţa
prezintă
importanţă
?
Secvenţială
Funcţională
Procedurală
Comunicaţională
Temporală
Logică
Coincidentală
5.3.1 Tipuri de coeziune a modulelor

Tipuri de coeziune a modulelor (cont.)
Coeziunea funcţională
este cel mai droit tip de coeziune
instrucţiunile modulului au ca obiectiv realizarea unei singure
funcţii
comportamentul acestor module este tipic cutiei negre
Exemple:
CALCUL_DOBÂNDĂ
ACTUALIZARE_STOC
CALCUL_IMPOZIT_SALARIU
 Rezervarea unui loc pentru un bilet de avion

Coeziunea secvenţială
 modulul realizează funcţii multiple de prelucrare
 asupra aceloraşi structuri de date
 ordinea în care sunt executate funcţiile este importantă
 rezultatele obţinute prin execuţia unei funcţii devin intrări pentru
următoarele
Exemplu:
 modulele care citesc datele dintr-un fişier, le prelucrează şi apoi le
afişează/tipăreşte într-o anumită formă
Dezavantaje:
 limitarea reutilizării unei funcţii interne
 întreţinerea dificilă a modulului

Coeziunea comunicaţială
 modulul realizează funcţii multiple de prelucrare
 asupra aceloraşi structuri de date
 ordinea în care sunt executate funcţiile nu este importantă
Exemplu: un modul proiectat pentru înregistrarea unei facturi, va
realiza:
 inserarea facturii în baza de date
 actualizarea soldului clientului
 actualizarea stocului pentru produsele vândute
 generarea notei contabile

Coeziunea procedurală
 modulul realizează funcţii multiple independente
 grupate pe baza fluxurilor de control
 ordinea în care sunt executate funcţiile este important – ele
trebuie executate intr-o ordine stabilita
Exemplu: un modul care verifica drepturile de access si apoi deschide fisierul

Coeziunea temporală
 modulul realizează funcţii multiple independente
 grupate pe baza factorului timp – adica ele sunt executate la
acelasi moment al rularii programului
 ordinea de execuţie a funcţiilor nu este importantă
Exemplu:
 modulele de iniţializare şi inchidere a programelor
 un modul este invocat la aparitia unei exceptii, care inchide
fisierul, adauga o inregistrare in fisierul jurnal (log) si notifica
utilizatorul

Coeziunea logică
 modulul realizează funcţii multiple
 grupate pe considerentul includerii lor într-o categorie generală
 urmărindu-se evitarea redundanţei în scrierea codului
 ordinea de execuţie a instrucţiunilor este dictată din afară, prin
intermediul unei informaţii de control
Exemplu:
 fişierele DLL din mediul WINDOWS

Coeziunea coincidentală
 modulul realizează funcţii multiple
 grupate cu totul întâmplător, ca urmare a neatenţiei
proiectantului sau din dorinţa acestuia de a economisi timp cu
activităţile de proiectare

Scopul cuplării este de reducere a interdependenţelor dintre module
 altfel, modificarea programelor va fi dificilă – propagarea modificărilor
Fără dependențe Cuplare slabă-unele dependențe
Cuplare mare-multe dependențe
5.3.2 Tipuri de cuplare a modulelor

5.3.2 Tipuri de cuplare a modulelor
Scopul cuplării este de reducere a interdependenţelor dintre module
Există cinci tipuri de cuplare
 la nivel de date elementare – data coupling
 la nivel de date grupate – stamp coupling
 la nivelul informaţiilor de control – control coupling
 la nivelul datelor comune – common coupling
 la nivel de conţinut – content coupling

Cuplarea prin date elementare
 constituie obiectivul proiectului
 modulele sunt total independente
 ele îşi transmit doar datele elementare necesare pentru ca
fiecare să-şi realizeze funcţia
Tipuri de cuplare a modulelor (cont.)
Inregistrare_livrare
Calcul_discount
vCodClient
vValFactura
vValDiscount
Exemplu

Cuplarea prin date grupate
 presupune transferarea datelor grupate sub formă de structuri
de date sau chiar înregistrări întregi
 creşte dependenţa dintre module
 ea este acceptabilă dacă toate datele elementare din structură
sunt valorificate de către modulele care le preia
Exemplu bun
Calcul_discount
vValDiscount DateFactura = vCodClient+vValFactura

Calcul_discount
vValDiscount DateFactura = cNrFactura+dDataFactura+vCodClient+vCodMaterialv+
vCantitate+ValFactura+vValoareTVA
Exemplu criticabil de coeziune prin date grupate

Cuplarea prin informaţii de control
 apare când coordonatele prelucrărilor se transmit de la un modul
la altul
 înseamnă că un modul „se va interesa” despre detaliile de
prelucrare internă ale altuia
Informaţiile de control sunt date elementare ce pot lua anumite valori
bine definite dintr-un domeniu finit de valori. Ex: variabilele booleene
(logice)
Inregistrare_comanda
Validare_client
vCodClient
vV alComanda
bS tareClient
Exemplu

Cuplarea comună
 intervine atunci când două sau mai multe module accesează în
comun aceleaşi date elementare aflate într-un loc comun, numit şi
bloc de date
 2 sau mai multe module auu acces la variabile globale
Declarare variabilă globală var_global
while (var_global == 0)
{
if (x > 25)
module_3 ();
else
module_4 ();
}

Cuplarea comună - dezavantaje
 risc mare de apariție a erorilor la momentul execuției programelor
 modificarea modulelor în cascadă
 dificultatea în reutilizare
 riscuri de securitate deoarece datele sunt expuse in mai multe module
chiar dacă nu sunt necesare
 dificultatea testarii

Cuplarea prin conţinut
 presupune implicarea directă a unui modul în intimitatea
prelucrărilor altuia
 de exemplu, un modul poate să schimbe datele altuia sau, mai
grav, să schimbe instrucţiunile acestuia

5.4 Introducere în UML
UML este un limbaj de modelare adoptat ca standard de OMG în 1997
Ultima versiune UML 2.5.1 – decembrie 2017
Un limbaj de modelare este format din:
 sistem de notaţie
 set de reguli sintactice, semantice şi practice
Tipuri de diagrame UML:
 diagrama cazurilor de utilizare
 diagrama claselor de obiecte
 diagrama obiectelor
 diagrama de secvenţe
 diagrama de comunicare
 diagrama de activităţi
 diagrama de stări
 diagrama de componente
 diagrama de implementare

5.4.1 Diagrama claselor de obiecte
Reprezentarea claselor
Elementele specificate la descrierea claselor:
 pentru atribute:
 numele şi tipul
 valori implicite
 vizibilitate (+, -, #, ~)
 valori posibile
 atributele de tip class scope sunt subliniate
 pentru operaţii:
 numele
 listă parametri
 tipul returnat
 operaţiile abstracte sunt evidenţiate cu font italic
 includerea stereotipului <Interface> pentru clasele de tip interfaţă

Reprezentarea relaţiilor dintre clase
Relaţii de asociere:
 numele sau rolurile şi sensul de citire
 multiplicitatea – relaţiile de tipul unu-la-unu trebuie analizate cu atenţie
 navigabilitatea – se evidenţiază atributele care implementează relaţia
 cum trebuie interpretată o relaţie de asociere?
 asocieri reflexive – între obiectele din aceeaşi clasă

Reprezentarea claselor de asociere
 nu este diferită de celelalte clase
 poate fi reprezentată şi ca două relaţii de
asociere între trei clase obişnuite
 relaţiile multe-la-multe sunt susceptibile de a
avea proprietăţi specifice

Relatie de dependenta Relatie de asociere navigabila Relatie de agregare
Alte tipuri de relatii

Relatie de mostenire
Relatie de realizare
Se mostenesc:
•Atribute
•Semnaturile metodelor
•Implementari de metode
Se mostenesc doar:
•Semnaturile metodelor
Alte tipuri de relatii

5.4.2 Diagrama de secvenţe (DS)
Introducere
 modelează aspectele dinamice ale sistemului (aplicaţiei) – relevă secvenţa mesajelor
schimbate între obiecte în vederea realizării unei funcţionalităţi
 relevă interacţiunile dintre obiecte – mesaje schimbate
principalele elemente ale DS:
 obiectele
 mesajele
 timpul - reprezentat ca progresie verticală

Reprezentarea obiectelor şi actorilor
 Obiectele sunt plasate în partea de sus a diagramei – ele există deja în momentul iniţierii
interacţiunilor
 Crearea unui obiect poate fi pusă în evidenţă prin plasarea sa mai jos, pentru a reflecta
momentul creării
 Distrugerea sa este evidenţiată printr-un X
 Actorii care iniţiază acţiuni pot fi plasaţi în rând cu obiectele şi – de obicei în partea stângă
a DS

Exemplu

Reprezentarea obiectelor şi actorilor
Fiecare obiect are ataşată o linie a vieţii – reprezentată ca o linie verticală întreruptă
pe linia vieţii sunt reprezentate activările – semnifică execuţia unei operaţiuni de către
obiect
Linia vieţii poate fi împărţită în mai multe ramuri - arată mesajele condiţionale - două
mesaje pot fi trimise unui obiect dar, la un moment dat, numai unul dintre ele, în funcţie de
condiţia specificată

Reprezentarea mesajelor
 interacţiunile apar sub forma mesajelor
 unesc liniile de viaţă a două obiecte
 unesc linia de viaţă a unui actor cu cea a unui obiect
 pot exista şi mesaje transmise de un obiect către el însuşi
 forma generală a mesajului: răspuns:=mesaj(argument,...)
 exemplu: factura:= getFacturaByDate(datai, dataf)
 tipuri de mesaje:
 simple (transferul controlului execuţiei unui alt obiect)
 sincrone
 asincrone
 mesajele pot fi însoţite de condiţii - arată când este transmis un mesaj şi când nu
 mesajul de răspuns poate fi evidenţiat printr-o linie întreruptă

Legătura cu DCO
 diagrama claselor de obiecte
 obiectele incluse în DS au corespondent în clasele din DCO
 interacţiunile (mesajele) din DS privesc metodele implementate în DCO
 navigabilitatea relatiilor de asociere
 nu se poate construi DS dacă anterior nu a fost creata DCO
 DCO descrie clasele de obiecte care vor realiza funcţionalităţile sistemului
 DS arată cum vor realiza funcţionalitatea (cazurile de utilizare) obiectele din sistem
 DS este utila in identificarea operatiilor omise in DCO
 DS pot fi utilizate la generarea automată a codului în instrumentele CASE

5.5 Şabloane (pattern) pentru dezvoltarea de software
5.5.1 Generalități despre şabloane
Definiţie:
 este o soluţie generalizată pentru rezolvarea unei anumite probleme comune într-un context dat
 este o pereche problemă/soluţie căreia i s-a atribuit un nume şi care poate fi aplicată într-un
context nou, împreună cu sfaturile de aplicare şi comentariile asupra compromisurilor sale
 şabloanele nu sunt invenţia cuiva! Ele statuiază o regulă sau un principiu utilizat pe larg în
practică
Exemplu:
 nume – Information Expert
 problema – care este regula de bază prin care se atribuie responsabilităţile obiectelor?
 soluţia – responsabilitatea este atribuită clasei care are informaţiile necesare realizării ei
Tipuri de şabloane
 şabloane economice (business patterns) – sunt aplicate în modelarea afacerii
 şabloane arhitecturale – se aplică în proiectarea arhitecturală
 şabloane de proiectare (design patterns) – sunt folosite pentru producerea unor soluţii tehnice
flexibile de proiectare a softului, fiind apropiate de activităţile de programare.

5.5.2 Șabloane arhitecturale
 Oferă soluţii formalizate la problemele proiectării arhitecturale a softului
 Faciliteză proiectarea de sisteme flexibile prin utilizarea de componente cât mai independente
 Specifică un set de:
 subsisteme predefinite,
 responsabilităţile lor,
 reguli şi principii de organizare a relaţiilor dintre subsisteme
 Nu reprezintă o arhitectură a unui software
5.5. Şabloane (pattern) pentru dezvoltarea de software

5.5.2.1 Şablonul multi-strat
 funcţionalitatea softului este împărţită în servicii, iar serviciile strâns legate între ele sunt
grupate într-un strat
 fiecare strat comunica numai cu straturile inferioare, iar de multe ori doar cu cel imediat
inferior – modelul OSI
 niciodată un strat nu va apela la serviciile furnizate de un strat superior
 fiecare strat are definit un API – grup de metode care defineşte serviciile furnizate
 Exemple de straturi:
 calcule şi alte prelucrări de date,
 transmiterea mesajelor sau a datelor,
 stocarea datelor
 managementul securităţii
 interacţiunea cu utilizatorii
5.5 Şabloane (pattern) pentru dezvoltarea de software

5.5.2.2 Şablonul client/server
 este utilizat la dezvoltarea sistemelor distribuite
structura aplicaţiei este gândită în termenii a două tipuri de componente:
 componente server – furnizează servicii în baza cererilor clienţilor
 componente client – iniţiază comunicarea cu componentele server în vederea obţinerii
unor servicii
 componentele server pot fi grupate pe mai multe straturi – arhitectura client/server pe mai multe
straturi
 modelul clasic prevede trei straturi: interfaţa utilizator, logica aplicaţiei şi baza de date
 se diferenţiază de şablonul multistrat prin natura relaţiilor dintre componente
 are la bază comunicarea inter-procese la distanta
 comunicarea între componentele client şi server are la bază protocolul cerere-răspuns.

5.5.2.3 Şablonul Model-View-Controller
Contextul
 majoritatea aplicaţiilor încarcă date din BD în interfaţa utilizator şi permite actualizarea lor
 separarea lor este necesară - interfaţa utilizator este mai frecvent supusă modificărilor decât
BD
 unele aplicaţii solicită afişarea aceloraşi date în forme (si interfețe utilizator) diferite
Soluţia - separarea stratului interfaţa utilizator de celelalte părţi ale aplicației prin considerarea a trei
categorii de clase: Model, View, Controller

 Obiectele Model nu cunosc obiectele View şi Controller care le sunt ataşate
 Componentele View şi Controller depind de componenta Model
Pentru detalii privind aplicarea MVC vezi modelul de la laborator.
Soluţia :
 Model – gestionează comportamentul şi datele specifice domeniului problemei
 răspunde la cererile de informaţii primite de la View
 răspunde la solicitările de actualizare a datelor venite de la Controller
 notifică View în legătură cu modificările de date intervenite (prin aplicarea
sablonului Observer)
 View – gestionează modul de afişare a datelor în interfața utilizator
 conectează obiectele grafice la datele modelului (citește modelul)
 inștiințează Controller-ul de evenimentele inițiate de utilizator
 executa logica de prezentare a datelor în interfața utilizator
 Controller - gestionează evenimentele iniţiate de utilizator prin GUI
 definește comportamentul/logica aplicației
 informează Model şi/sau View despre schimbările intervenite asupra datelor
5.5.2.3 Şablonul Model-View-Controller

Şablonul
Model-View-Controller
Proiect studiu de caz
de la laborator
-Utilizatorul adauga
document, specifica tipul de
operatie, selecteaza furnizor
-Controllerul apeleaza
serviciile modelului
-Modelul creeaza o instanta
de DocInsotitor, atribuie
valori variabilelor de instanță
și returneaza obiectul
Controllerului

Context:
În cazul multor aplicații software, funcțiile din stratul “logica aplicației” acceseaza datele din
surse de date cum ar fi baze de date, liste SharePoint sau servicii web. Accesarea directă a
datelor poate avea ca efect:
 Cod redundant, care se repetă;
 Probabiliate mare de aparitie a erorilor de programare
 Dificultăți în testarea logicii aplicației independent de dependențele externe
Obiective:
Se dorește separarea/ izolarea accesului la date pentru ușurarea testării funcțiilor din
stratul de logica aplicației și creșterea posibilității de testare automată a codului.
Se dorește gestionarea centralizată și unitară a regulilor și logicii de acces la date în
contextul în care aceeași sursă de date este accesată din mai multe locații din aplicație.
Se dorește îmbunătățirea mentenabilității și lizibilitării codului, prin separarea logicii
afacerii de logica accesului la date
5.5.3 Pattern-ul Repository

Soluția:
 Utilizarea unei clase cu rol de repository pentru a separa logica de furnizare a datelor și
mapare a lor cu entitățile aplicației de logica aplicației care utilizează clasele entități
 Clasa repository ofera servicii CRUD
Logica afacerii trebuie să fie agnostică față de tipurile de date care sunt conținute în
sursa de date (baza de date, lista SharePoint sau serviciu Web).
 Clasele repository mediază între stratul de date și celelalte straturi ale aplicației.
• interoghează sursa de date
• mapează datele din baza de date cu entitățile din domeniu.
• salvează în baza de date modificările efectuate asupra entităților (domain model).
5.5.3 Pattern-ul Repository

5.6 Arhitectura aplicației SGSM.
Modelul general al arhitecturii aplicatiei de la laborator

5.6 Arhitectura aplicației SGSM. Proiectarea componentei pentru gestiune a datelor
1. public class FirstTest{
2. public static void main(String[] args){
3.
4. EntityManager em = Persistence.createEntityManagerFactory(
"SGSMPersistenceUnit").createEntityManager();
5. em.createQuery("Select loc from Localitate loc").getResultList();
6.
7. }
8. }
1. public class SecondTest{
3.
4. EntityManager em = Persistence.createEntityManagerFactory(
"SGSMPersistenceUnit").createEntityManager();
5. em.getTransaction().begin();
6. Localitate loc = new Localitate();
7. loc.setCod(100 + i);
8. loc.setDenumire("Localitate " + (100 + i));
9. em.persist(loc)
10. em. getTransaction().commit()
11. }
12.}
Cum este scrisă aplicația-client

class repository
«interface»
DocumentRepository
+ saveDocument(Document) : Document
DocumentRepositoryDefault
«interface»
MasterRepository
+ addLocalitate(Localitate) : Localitate
+ addFurnizor(Furnizor) : Furnizor
+ addBunMaterial(BunMaterial) : BunMaterial
+ addGestiune(Gestiune) : Gestiune
+ updateLocalitate(Localitate) : Localitate
+ updateFurnizor(Furnizor) : Furnizor
+ updateBunMaterial(BunMaterial) : BunMaterial
+ updateGestiune(Gestiune) : Gestiune
+ deleteLocalitate(Localitate) : void
+ deleteFurnizor(Furnizor) : void
+ deleteBunMaterial(BunMaterial) : void
+ deleteGestiune(Gestiune) : void
+ findLocalitatiAll() : List<Localitate>
+ findFurnizoriAll() : List<Furnizor>
+ findBunuriMaterialeAll() : List<BunMaterial>
+ findGestiuniAll() : List<Gestiune>
+ findLocalitateById(Long) : Localitate
+ findFurnizorById(Long) : Furnizor
+ findBunuriMaterialById(Long) : BunMaterial
+ findGestiuneById(Long) : Gestiune
+ findFurnizoriAllLight() : List<Furnizor>
MasterRepositoryDefault
«interface»
metamodel::
TransactionManagement
+ beginTransaction() : void
+ commitTransaction() : void
metamodel::AbstractRepository
- em: EntityManager = Persistence.cre...
+ beginTransaction() : void
+ commitTransaction() : void
+ create(Object) : Object
+ update(Object) : Object
+ delete(Object) : void
+ getEm() : EntityManager
+ setEm(EntityManager) : void

Cum este scrisă aplicația-client prin aplicarea șablonului Repository
1. public class FirstTest{
3.
4. static MasterRepository repo = new MasterRepositoryDefault();
5. localitati = repo.findLocalitatiAll();
6.
7. }
8. }
1. public class SecondTest{
3.
4. static MasterRepository repo = new MasterRepositoryDefault();
5. repo.beginTransaction();
6. localitate loc = new Localitate();
7. loc.setCod(100 + i);
8. loc.setDenumire("Localitate " + (100 + i));
9. repo.addLocalitate(loc);
10. repo.commitTransaction();
11.
12. }
13. }

class forms
AchizitiiForm
+ NECUNOSCUT: String = "Necunoscut" {readOnly}
+ STORNARE: String = "Stornare" {readOnly}
+ AVIZ: String = "Aviz" {readOnly}
+ FACTURA: String = "Factura" {readOnly}
- formData: AchizitiiFormData = new AchizitiiFo...
+ getFormData() : AchizitiiFormData
+ setFormData(AchizitiiFormData) : void
+ documentNou() : void
+ adaugaReceptie() : void
+ adaugaLinieReceptie() : void
+ salveazaModificariDocument() : void
AchizitiiFormData
+ STORNARE: String = "Stornare" {readOnly}
+ FACTURA_INTARZIATA: String = "Factura intarziata" {readOnly}
+ ACHIZITIE_CU_AVIZ: String = "Achizitie cu Aviz" {readOnly}
+ ACHIZITIE_CU_FACTURA: String = "Achizitie cu f... {readOnly}
- documentCurent: DocInsotitor
- listaDocumente: List<DocInsotitor>
- masterRepo: MasterRepository = new MasterRepos...
- docRepo: DocumentRepository = new DocumentRep...
- listaFurnizorilor: List<Furnizor>
- operatiuni: List<String>
- operatieSelectata: String
- receptieSelectata: Receptie
- listaGestiuni: List<Gestiune>
- listaMateriale: List<BunMaterial>
+ getListaFurnizorilor() : List<Furnizor>
+ setListaFurnizorilor(List<Furnizor>) : void
+ getFurnizorSelectat() : Furnizor
+ setFurnizorSelectat(Furnizor) : void
+ getOperatiuni() : List<String>
+ getOperatieSelectata() : String
+ setOperatieSelectata(String) : void
+ getArticoleReceptionate() : List<LinieDocument>
+ getReceptieSelectata() : Receptie
+ setReceptieSelectata(Receptie) : void
+ getListaGestiuni() : List<Gestiune>
+ getListaMateriale() : List<BunMaterial>
+ getDocumentCurent() : DocInsotitor
+ setDocumentCurent(DocInsotitor) : void
+ getListaDocumente() : List<DocInsotitor>
+ setListaDocumente(List<DocInsotitor>) : void
+ getMasterRepo() : MasterRepository
+ setMasterRepo(MasterRepository) : void
+ getDocRepo() : DocumentRepository
+ setDocRepo(DocumentRepository) : void
AbstractEntity
entities::Furnizor
AbstractEntity
entities::Gestiune
AbstractEntity
entities::BunMaterial
Document
entities::Receptie
Document
entities::DocInsotitor
«interface»
repository::DocumentRepository
«interface»
repository::MasterRepository
-formData
«use»
«use» «use»
«use» «use»
-docRepo
-masterRepo
5.6 Arhitectura aplicației SGSM. Proiectarea comportamentului specific formularului

Aplicatia client (sau de test)
……
AchizitiiForm form = new AchizitiiForm();
form.salveazaModificariDocument();
.....
Metoda din clasa Controller (AchizitiiForm)
public void salveazaModificariDocument() {
this.getFormData().getDocRepo().beginTransaction();
this.getFormData().getDocRepo().saveDocument(this.getFormData().getDocumentCurent());
this.getFormData().getDocRepo().commitTransaction();
}
Metoda din clasa Repository (DocumentRepositoryDefault)
public Document saveDocument(Document document) {
if (document.getId()==null)//obiect nou
document=(Document)this.create(document);
else //obiect existent in BD
document=(Document)this.update(document);
return document;
}
Metoda Create() mostenita din AbstractRepository
public Object create(Object o) {
this.getEm().persist(o);
return o;
}

sd forms
:AchizitiiForm :AchizitiiFormData :DocumentRepositoryDefault EntityManager DB
beginTransaction()
getTransaction().begin()
getDocumentCurent() :DocInsotitor
getDocRepo() :
DocumentRepository
saveDocument(Document) :Document
[id!=null]:update(Object) :Object
merge(Object)
UPDATE SQL()
[id==null]:create(Object) :Object
persist(Object)
INSERT SQL()
commitTransaction()
getTransaction().commit()

Capitolul 5_ProiectareaProgramelor2020.ppt

Recommended

Recommended

More Related Content

Featured

Featured (20)

Capitolul 5_ProiectareaProgramelor2020.ppt