1 Medii de proiectare si programare Curs 1 Modelarea REA pt. procesele business 1. Resurse, evenimente, agenti 2. Studiu de caz: procesul de… [623169]

1 Medii de proiectare si programare Curs 1

Modelarea REA pt. procesele business
1. Resurse, evenimente, agenti
2. Studiu de caz: procesul de aprovizionare
3. Proiectarea bazei de date

1. Resurse, evenimente, agenti
Modelarea REA a fost propus ă inițial ca un model general pentru procesele business , de că tre William E.
McCarthy, de la Universitatea Michigan din SUA . McCarthy a an alizat un num ăr mar e de tranzacții
economice , identificând caracteristicile lor comune ș i a formulat ace astă model are general ă ce descrie și
explică tranzacț iile economice . Ulterior modelarea REA a fos t extins ă de către McCarthy ș i G. Geerts, spre
un framework pentru arhitectur a informaț ional ă a companiilor și o ontologie pe ntru sistemele business .
Modelarea REA a devenit o bază pentru câ teva standarde, ca de exemplu ebXML ș i Open -edi (standard
ISO).
Modelul inițial utiliza trei categorii conceptuale: resursă , eveniment și agent precum și o serie de relații de
asociere standard î ntre aceste categorii conceptuale.
Resursa este ceva care are valoare și utilitate pentru agenții economic i, făcând obiectul planificării,
monitorizării și conducerii . Exemple de resurse economice ar fi: produse, servicii, bani, mat erie primă,
munca angajaț ilor, utilaje etc . Evalua rea u nei resurse economice trebuie să se raporteze la un anumit
moment de timp.
Agentul este o persoană sau organizație capabilă să aibă contr ol asupra resurselor și care să poată transfera
sau primi controlul, spre sau de la, alte perso ane sau organizaț ii. Exem ple de agenți ar fi: clienți, furnizori,
organizatia insasi etc. Organizatia este un agent din per spectiva c ăreia realiz ăm modelarea proceselor
business .
Evenimentul reprezintă fie o creș tere (incremen tare) fie o descreș tere (decrementare) a unei resurse ce se
gaseș te sub controlul organizatiei . Exemple d e evenimente ar fi: vâ nzarea d e bunuri sau servicii, achiziț ia de
muncă angajată , aprovizionare a cu bunuri sau servicii, etc. Evenimentele se pro duc la anumite moment e de
timp.
Conceptele mai sus mentionate pot fi reprezentate prin clase si astfel putem construi diagrame UML de
clase.
2. Studiu de caz: procesul de aprovizionare
Vom considera in continuare un proces business ce apare in majoritatea companiilor: procesul de
aprovizionare. Acest proces consta in achizitionarea de bunuri si/sau servicii de la un furnizor, efectuarea
platii aferente si eventual stocarea bunurilor in vederea utilizari i lor (comert, productie, servicii etc).

Identificam 3 evenimente, 2 resurse si un agent. Compania insasi, din punctul de vedere al careia se descrie
procesul business este implicita.

2 Medii de proiectare si programare Curs 1

Procesul business pentru activitatea de aprovizionare
Modelul REA s -a extins cu un nou concept , cel de tip pentru resurse, agenti sau evenimente. Noi vom folosi
conceptul de tip , pentru resurse.

Diagrama conceptuala extinsa cu tipuri de resurse

Transformarea modelului prin i ntroducerea cardinalităț ilor pentru rela țiile de asoci ere
Un element important în rafinarea modelului il constituie specificarea cardinalit ăților pentru rela țiile de
asociere dintre concepte. Vom lua în considerare urm ătoarele tipuri de cardinalit ăți:
0..1 cel mult o asociere one
1 o singur ă asociere one required
0..* oricâ te asocieri many
1..* cel pu țin o asociere many required

Transformând diagrama de la secț iunea anterioară se obț ine urmatoarea diagrama :
<<resursă>>
StocProduse
<<eveniment>>
Recepție
intrare
<<eveniment>>
FacturareAchiziție
consec ință
<<agent>>
Furnizor
furnizare
<<eveniment>>
Plată
dualitate
<<resursă>>
StocLichidități
Ieșire
primire
<<resursă>>
StocPro duse
<<eveniment>>
Recepție
intrare
<<eveniment>>
FacturareAchiziție
consecință
<<agent>>
Furnizor
furnizare
<<eveniment>>
Plată
dualitate
<<resursă>>
StocLichidități
iesire
primire
<<tip resursa>>
Produs
specificare
specificare
<<tip resursa >>
Trezorerie
specificare
specificare

3 Medii de proiectare si programare Curs 1

Diagrama conceptuala extinsa cu cardinalitati
De remarcat că, în figura de mai sus, relațiile de asociere intrare respectiv ieșire dintre conceptele resursă și
eveniment nu au marcate cardinalit ăți. Am considerat c ă în aceste cazuri, cardinalitățile nu au relevanță .
Setul de diagrame reprezinta totodata un exemplu de rafinare a modelarii. Se in cepe cu un model simplificat
ce contine principalele concepte iar a poi se extinde modelul cu detalii supli mentare.

Transformarea modelului prin i ntroducerea conceptului evenimentDetaliu
In diagrama anterioara se observa doua asocieri avand cardinalitati many to many. Vom introduce un nou
concept evenimentDetaliu asociat conceptel ui eveniment pentru a putea detalia relatiile de asociere
mentionate.
Relaț ia de asociere dintre conceptul evenimentDetaliu și conceptul eveniment a fost etichetată cu stereotipul
detaliu . Conceptul evenimentDetaliu devine un intermediar î ntre concept ul eveniment și celelalte c oncept e
cu care acesta avea relații de asociere. Relația de asociere consecință dintre conceptele eveniment se
transferă acum între conceptele evenimentDetaliu . Dintr -o perspec tivă spre proiectare, introducerea
conceptul ui evenimentDetaliu transform ă relațiile de asociere many to many în rela ții de asociere one to
many ce sunt mai u șor de implementat.
Introducâ nd conceptul evenimentDetaliu , se obț ine di agrama urmatoare de mai jos.

<<resursă>>
StocPro duse
<<eveniment>>
Recepție
intrare
<<eveniment>>
FacturareAchiziție
consecință
<<agent>>
Furnizor
furnizare
<<eveniment>>
Plată
dualitate
<<resursă>>
StocLichidități
iesire
primire
<<tip resursa>>
Produs
specificare
specificare
<<tip resursa >>
Trezorerie
specificare
specificare

4 Medii de proiectare si programare Curs 1

Diagrama conceptuala extinsa cu evenimenteDetaliu
Transformarea modelului prin i ntroducerea conceptelor arhivaResursă asociate conceptelor resursă
Conceptul de tip resursă reprezintă evaluarea la momentul curent a unei resurse a întreprinderii. Unui
concept de tip resurs ă i se asociaz ă, prin prezenta metodologie, un concept de tip arhiv ăResurs ă. Arhiva unei
resurse con ține evaluă ri ale acelei resurse la diverse momente de timp (de obicei începutul unei luni
calendaristice). Utili zarea arhivelor pentru resurse este extrem de util ă în procesul de evaluare a unei resurse
la un moment de timp (prezent sau trecut). Procesul de evaluare a unei resurse la un moment de timp t (t > t s
, unde t s este momentul de start al utilizarii aplica ției) pleac ă de la cea mai recent ă arhivare , din momentul t a
≥ ts și ia în considerare doar evenimentele de intrare și de ieșire pentru resursa respectiv ă, din intervalul de
timp [ ta , t). Introduc ând conceptul arhiv ăResurs ă pentru conceptele resurs ă, se ob ține diagrama conceptual ă
din figura de mai jos .
Relația de asociere dintre conceptual arhivaResurs ă și conceptual resurs ă a fost etichetat ă cu numele
arhivare .
Ca și în cazul rela țiilor de asociere de tip intrare și ieșire dintre conceptele de tip resursă și conceptele de tip
eveniment, c ând nu am specificat cardinalit ăți, nici pentru rela țiile de asociere arhivare, cardinalitatea nu
este relevant ă.

<<resursa>>
StocProduse
<<eveniment>>
Recepție
<<eveniment>>
FacturareAchiziție
<<agent>>
Furnizor
furnizare
<<eveniment>>
Plată
<<resursă>>
StocLichidit ați
primire
<<tip resursă>>
Produs
specificare
<<tip resurs a>>
Trezorerie
0..*
1
0..*
1
1..*
0..*
<< evenimentDetaliu >>
FacturareAchizițieDetaliu
<<evenim entDetaliu>>
RecepțieDetaliu
<<evenimentDetaliu>>
PlatăDetaliu
detaliu
ieșire
detaliu
detaliu
consecință
dualitate
1
1
1
1
1
0..*
specificare
1
1
1..*
0..1
1..*
0..*
1..*
0..*
intrare
specificare
specificare
1
1
1
0..*

5 Medii de proiectare si programare Curs 1

Completarea modelului prin specificarea atributelor conceptelor
Procesul de rafinare a specifica țiilor conceptuale continu ă cu introducerea atributelor pentru concepte.
Vorbim în această fază de atribute conceptuale, ce reprezint ă caracteristici intrinseci ale conceptelor.
Atributele pot fi reprezentate în cadrul diagramelor conceptuale, ca atribute ale claselor din diagrama de
clase UML. Pentru simplitate vom prezenta atributele sub forma unor liste asociate conceptelor, specificând
pentru fiecare atribut numele, tipul de date și obligativitat ea completării valorii sale. Obț inem astfel
următoarea specificare:

<<resursa>>
StocProduse
<<eveniment>>
Recepție
<<eveniment>>
FacturareAchiziție
<<agent>>
Furnizor
furnizare
<<eveniment>>
Plată
<<resursă>>
StocLichidit ați
primire
<<tip resursă>>
Produs
specificare
<<tip resurs a>>
Trezorerie
0..*
1
0..*
1
1..*
0..*
<< evenimentDetaliu >>
FacturareAchizițieDetaliu
<<evenim entDetaliu>>
RecepțieDetaliu
<<evenimentDetaliu>>
PlatăDetaliu
detaliu
ieșire
detaliu
detaliu
consecință
dualitate
1
1
1
1
1
0..*
specificare
1
1
1..*
0..1
1..*
0..*
1..*
0..*
intrare
specificare
specificare
1
1
1
0..*
<<arhiva >>
Arhi vaStocProduse
<<arhiva>>
ArhivaSto cLichiditati
arhivare
arhivare
Produs
DProdus Text(100) Required
Um Te xt(10) Required
CotaTVA Single Required
Stocabil Boolean Required
PrețVanzare Currency

Trezorerie
DTrezorerie Text(100) Required

Furnizor
DFurnizor Text(50) Required
CodFiscal Text(15) Required
Localitate Text(30) Required
Adresa T ext(100) Required

FacturareAchiziție
NrDocument Long Required
DataDocument Date Required
DataInregistrarii Date Required

FacturareAchizițieDetaliu
Nrc Integer Required
PrețAchizitie Currency Required
Cantitate Double Required
CotaTVA Single Required
Valoare Currency Required
ValoareTVA Currency Required
Recepție
NrDocument Long Required
DataDocument Long Required
RecepțieDetaliu
Nrc Integer Required
Cantitate Double Required
Plata
TipDocument Text(30) Required
NrDocument Long Required
DataDocumen t Date Required
PlataDetaliu
Nrc Integer Required
Suma Double Required

6 Medii de proiectare si programare Curs 1

3. Proiectarea bazei de date
StocProduse (IdProdus, DataDocument, Cantitate, IdRecepțieDetaliu)
StocLichidități (IdTrezorerie, Cantitate)

ArhivăStocProduse (Data, IdProdus, DataDocument, Cantitate, IdRecepțieDetaliu)
ArhivăStocLichidități (Data, IdTrezorerie, Cantit ate)

Produs (IdProdus, DProdus, Um, CotaTVA, Stocabil, PretVanzare )

Trezorerie (IdTrezorerie, DTrezorerie)

Furnizor (IdFurnizor, DFurnizor, CodFiscal, Localitate, Adresa)

FacturareAchizitie (IdFacturareAchi zitie, NrDocument, DataDocument, DataInregistrarii,
IdFurnizor)

FacturareAchizitieDetaliu (IdFacturareAchizitieDetaliu, Nrc, PretAchizitie, Cantitate,
CotăTVA, Valoare, ValoareTVA, IdProdus, IdFacturareAchizitie)

Recepție (IdRecepție, NrDocument, DataDocument, IdFacturareAchizitie)
RecepțieDetaliu (IdRecepțieDetaliu, Nrc, Cantitate, IdRecepție, IdFacturareAchizițieDetaliu)

Plată (IdPlată, TipDocument, Nr Document, DataDocument, IdTrezorerie, IdPartener)

PlatăDetaliu (IdPlatăDetaliu, Nrc, Suma, IdFacturareAchiziție, IdPlată)

CotăTVA (CotăTVA)
UM(Um)