Universitatea Tehnică a Moldovei

Facultatea Calculatoare, Informatică și Microelectronică

Departamentul Ingineria Software şi Automatică

Proiect de an
Disciplina “ Analiza și Modelarea Orientată pe Obiecte ”
Tema: Analiza și modelarea unui sistem de gestiune a bazelor de date

A elaborat : st.gr.TI – 171 f/r , Florea Cristina

A verificat : prof.univ. Nina Sava,
prof.univ. Radu Melnic

Chişinău 2019
 Cuprins
Introducerea.................................................................................................................................................2
1. Analiza domeniului problemei............................................................................................................3
2.1. Diagrama Use – Case....................................................................................................................6
2.2. Diagrama de secvență...................................................................................................................8
2.3. Diagrama de colaborare.............................................................................................................10
2.4. Diagrama claselor.......................................................................................................................12
2.5. Diagrama stărilor........................................................................................................................15
2.6. Diagrama activităților................................................................................................................16
2.7. Diagrama componentelor...........................................................................................................18
2.8. Diagrama de desfășurare............................................................................................................20
Concluzie.....................................................................................................................................................21
Bibliografie.................................................................................................................................................22

1
 Introducerea

Atunci când vine vorba despre crearea unui sistem ce va putea corespunde tutoror cerințelor
stabilite , unul din cele mai importanți pași în crearea lui este proiectarea sistemul. Această etapă este
necesară să fie făcută cu mare precauție, deoarece în baza proiectării realizate se va contrui și restul
sistemului.

Deoarece proiectarea sistemului nu e altceva decât baza, temelia acestui sistem , orice eroare
admisă în procesul de proiectarea poate avea consecințe destul grave și poate duce, în cel rău caz la
refacerea completă al sistemului . Acest lucru este costisitor atât din punct de vedere a timpului cât și a
banilor.

În procesul proiectării sistemului, trebuie să fie luat în considerații următoarele lucruri :

1. Sistemul proiectat trebuie să fie logic construit,cu o structură bine determinată : orice componentă
a sistemului trebuie să fie la locul său . În sistemul proiectat nu trebuie să existe componente în
plus,componente ce pot duce la defectul altor elemente . De asemenea, este de dorit de exclus
componentele redundate , care pot fi parte al altor componente . Legăturile trebuie să fie logice și
evidente.
2. Sistemul proiectat trebuie să fie ușor de înțeles : este necesar ca persoanele ce realizează acest
sistem , și persoanele care vor utiliza produsul final să înțeleagă clar care e funcționalitatea acestui
sistem . Fiecare atribut descris trebuie să aibă un nume concret. Fiecare entitate trebuie să fie
descrisă exact la ceea la ce se referă aceasta .
3. Sistemul proiectat trebuie să facă doar ceea de ce este nevoie : la proiectarea sistemului este bine
să știm răspunsul la întrebarea pentru ce este creat acest sistem și care ,defapt, este scopul lui .
Atunci când avem un scop bine stabilit și cunoaștem care vor fi funcționalitățile de bază a
sistemului, putem cu ușurință să omitem lucrurile inutile. Astfel, excludem părți din sistem care
defapt nu prezintă nici un folos măcar pentru un component.

La etapa de proiectare, o bună parte din ea reprezintă use-case-urile. Prin intermediul acestora putem
descrie variantele folosirii viitorului sistem de către utilizatori,putem vizualiza interacțiunea user – sistem,
și în același timp putem observa avantajele și neajunsurile sistemului . Totodată însă, trebuie să fim atenți
cu suprautilizarea acestora: utilizarea excesivă a use-case-urilor poate duce la complicarea sistemului,
care la rândului lui va ridica numărul de resurse necesare pentru realizarea acestui sistem . Astfel, pot
apărea componente de prisos, se mărește termenul de realizarea a acestuia și ca la final, nu se încadrează
în suma alocată pentru proiectarea acestui sistem.

2
 1. Analiza domeniului problemei
Enterprise Architect reprezintă un instrument cu multe capabilități, ce ajută utilizatorul să
gestioneze informația în medii complexe și cu cerințe avansate. Enterprise Architect furnizează
utilizatorilor tehnologii de modelare și construcții de ultima generație.

Enterprise Architect este utilizat de mai multe organizații cu renume, în peste 160 țări. Aplicați s-a
dezvoltat în continuu de 15 ani, pentru a satisface nevoile programatorilor, analiștilor , arhitecților,
dezvoltatorilor , etc. Produsul dat este bazat pe standarte deschise și s-a dovedit a fi eficient în
soluționarea nenumăratelor cazuri . Enterprise Arhitect se poate scala foarte ușor în funcție de mediu. Ca
spre exemplu, soluția se poate scala de la un model cu un singur utilizator , la un model complex, destinat
echipelor mai mari de utilizatori sau chiar funcționării în cloud.

Enterprise Architect furnizează capacități de modelare pentru următoarele medii :

1. Sisteme IT și Business
2. Inginerie pentru Software și Sisteme
3. Medii de dezvoltare în timp real.

Enterprise Architect are capabilități integrate pentru gestionarea cu scopul de a urmări diverse
stagii ale unui proiect , precum : analiza , dezvoltatea, implementarea , testarea și maintenața . Această
soluție folosește standarde deschise precum : UML,SysML,BPMN,etc.

Enterprise Architesct reprezintă un instrument grafic, cu capabilități multi-utilizatori , cu

obiectivul creării de sisteme robuste pentru maintenanță.

De asemenea, produsul are integrate funcții pentru raportare și documentare, cu scopul generării
unei imagini complete asupra diverselor procese.

Produsul dat este extrem de rapid și poate încărca modele complexe într-un timp foarte scurt. Are
integrat un repozitoriu pentru modele de înaltă performață , cu scopul acomodării nevoilor echipelor mari
de utilizatori .

Capabilitățile integrate pentru control al versiunii le permit echipelor distribuite diferit geografic
să colaboreze eficient.

Simulare Business

Modelele generate de aceast instrument pot fi îmbunătățite, folosind funcții de simulari dinamice
pentru modele. De asemenea, soluția poate să verifice corectitudinea modelelor, cu scopul înțelegerii
modului în care funcționează un sistem business.

Enterprise Architect poate să controleze modalitatea în care decurge o simulare , folosing Guards
și Effects scrise în JavaScript. Guards determină ce cale va fi aleasă în funcție de criterii ,precum parola
introdusă. Utilizatorul poate să controleze simulările folosind Effects cu scopul manipulării variabilelor și
efectuării de calcile la anumite intervale de timp. Viteza unei simulări poate fi controlată cu scopul
observării etapelor greu de observat.

Utilizatorul poate să adopte decizii diferite pentru a efectua schimbări asupra unei simulări într-un
mediu supus riscurilor. Produsul permite introducerea de punct de rupere pentru analizarea deciziilor și
3
îmbunătățirea rezultatelor oferite de business.Simularea poate să îmbunătățească comunicarea și astfel
complexitatea este redusă cu mult .

Urmărire Completă

Enterprise Architect poate urmări orice : cerințe, analiza, modele de dezvoltare, implementare,
instalare . Soluția poate efectua veirificări , validări și analiza impactului, folosind capabilități precum :
Enterprise Architect Relationship Matrix și Hierarchy View

Folosind acest produs , managerii de proiectate, dezvoltatorii și echipele de intervenție vor avea la
dispoziția lor informațiile necesare pentru a rezolva orice problemă .

Modelează , gestionează și urmărește cerințele.

Analiza impactului urmărește impactul provocat de schimnările aduce la cerințele originale .

Capabilitățile produsului dat pot fi folosite pentru următoarele cazuri :

- Definirea unui model organizat pentru cerințe

- Urmărirea implementării cerințelor de sistem pentru elemente de tip model
- Caută și raportează cerințe
- Efectuează analiza impactului schimbărilor ce au loc în domeniul cerințelor

Gestionearea complexității

Enterprise Architect ajută indivizii,grupurile și organizațiile mari să-ți modeleze și gestioneze

informațiile complexe. Prin integrarea și conectarea de informații structurale într-o formă vizuală,
utilizatorul poate să creeze un model coerent pentru situații de tipul ce este și ce va fi .

Uneltele integrate în acest soft ce pot ajuta utilizatorul să gestioneze complexitatea inclus:

- Diagrame pentru modelarea conceptelor strategice și business

- Profile specifice pentru domeniu și modelele reutilizabile
- Gestionarea versiunilor pentru urmărirea și integrarea schimbărilor
- Securitate în funcție de rol pentru garantarea faptului că oamenii potriviți au accesul potrivit.

Generare de documente.

Enterprise Architect furnizează funcții pentru generarea de documente și unelte pentru raportare,
fiind inclus și un editor complet WYSIWYG pentru șabloane. Soluția poate genera rapoarte detaliate
complete pline de informații necesare utilizatorului în formatul de care are nevoie organizația

Generarea și ingineria inversă a codului sursă

Enterprise Architect suportă generarea și ingineria inversă a codului sursă în mai multe limbaje de
programare: ActionScript, Ada, C și C++, C#, Java, Delphi, Verilog, PHP, VHDL, Python, System C,
VB.Net, Visual Basic și altele.

Editorul integrat pentru codul sursă îi permite utilizatorului să navigheze ușor de la un model în
direct către codul sursă în același mediu . Șabloanele pentru generarea de cop îi permit utilizatorului să
customizeze codul sursă, în funcție de nevoile companiei .
4
 Compilarea și vizualizarea codului de execuție

Enterprise Architect îi permite utilizatorlui să contruiască , să testeze și să execute scripturi de

implentare, folosind doar mediul de dezolvate Enterprise Architect.

Folosind abilitatea de generare a claselor de test Nunit și Junit din clase sursă cu ajutorul
transformărilor MDA, utilizatorul poate să integreze procesul de testare direct în Enterprise Architect
IDE. Enterprise Architect include și capabilități pentru Java, NET și Microsoft Native (C++, C și VB)

Funcțiile de rezolvare a problemelor din codurile scrise integrate în Enterprise Architect sunt
create special pentru a ajuta dezvoltatorul sau utilizatorul ce se ocupă de testarea să descopere problemele
apărute în cod sau să inspecteze coduri scrise pas cu pas .

Automatizare.

Interfața pentru automatizare permite acces utilizatorului către modele Enterprise Architect.
Exemple de sarcini ce pot fi efectuate folosind interfața pentru automatizarea sunt :

- Publicarea și generarea automată de rapoarte HTML în intranetul local

- Scriptarea de sarcini repetitive precum actualizarea elementelor din toate modelele
- Generarea de cod folosind o mașina sau diagramă
- Producția de rapoarte customizate
- Execuția de cerințe ad-hoc pentru modele .

Modelarea bazelor de date

Enterprise Architect suportă modelarea schemei bazei de date și generarea automată a codurilor
DDL pentru următoarele baze de date :

- DB2
- Firebird
- MS Access
- MySQL
- MS SQL Server
- Oracle
- PostgreSQL

Modelarea procesului de business

Există multe abordări când vine vorba de modelarea procesului de business, folosind UML drept
limbajul pentru modelare . Diagramele de activități, diagramele pentru obiecte și profilele customizate
furnizează abordări puternite pentru analiștii de afaceri .

Capabilitățile Enterprise Architect Business Process Modeling permit :

- Vizualizarea procesului business folosing un profil UML pentru BPMN

- Generarea de coduri executabile BPEL folosind modele BPMN
- Validarea corectitudinii modelor BPMN

5
 2. Proiectarea sistemului informațional

Pentru a proiecta un sistem de gestiune a bazelor de date , este necesar în primu rând de a opține
cunoștințe teoretice despre tema aleasă .

Sistemele de gestiune a bazelor de date ( SGBD sau DBMS ) nu este altceva decât totalitatea
programelor utilizate pentru crearea, interogarea și întreținerea une baze de date . SGBD include două
categorii de module :
- Module care sunt comune cu cele ale sistemelor de operare ale calculatoarelor
- Module cu funcții specifice bazei de date
.Pentru a înțelege mai clar funcționalitatea sistemelor de gestiune a bazelor de date, vom contrui
diagrame.

2.1. Diagrama Use – Case

Fig.1 DB Facilities

În prima diagramă ( Fig.1) descriem în primul rând care sunt facilitățile bazelor de date și cine au
acces la acelea facilități . Observăm că baza de date (DB) se află în legătură de dependență cu Actorul
Server, adică fără funcționalitatea DB depinde în primul rând de Server . Dacă Serverul nu funcționează –
nu funcționează nici baza de date .
De asemenea, din figura de mai sus observăm și facilitățile pe care le oferă Actorul DB , adică :
căutarea, afișarea informației , modificarea/actualizarea, introducerea datelor și ștergerea acestor.
Totodată observăm și legăturile dintre acestea și actorul User și actorul Admin . Din diagrama
noastră se vede clar că actor User are relație de asociere cu use – case – ul Search și Diaply Data , adică
Userul simplu poate doar căuta și afișa informația la ecran . În același timp observăm că actorul Admin
are relație de asociere cu toate use – case – urile de pe ecran, adică poate utiliza orice opțiune a DB .
De asemenea, observăm că este și o mică notiță legată la use – case –ul Display Data pentru a
specifica cum informația va fi afișată .

6
 Fig.2 Admin’s responsabilities

La a doua diagramă, după cum observăm , am studiat mai profund responsabilitățile

administratorul. După cum se vede în diagramă , administratorul are 3 funcții principale : controlul
accesului , controlul utilizatorul ,și maintenanța sistemului . Use – case – Manage Acces, după cum se
vede pe schemă , include alte Use – Case – uri : oferă drepturi și interzice acces la unele date . La use –
case – ul System Maintenance și use – case – ul Manage Users observă același lucru .
Deci , în această diagramă am organizat mai clar și mai citeț care sunt responsabilitățile
administratorului .

Fig.3 Types of DB

Pentru a putea proiect un SBGD este necesar de a stabili în primul rând ce tipuri sunt și care sunt
facilitățile acestor.
În Fig.3 observăm structurarea SBGD-urilor , adică tipurile care pot fi , și care sunt pricipiile lor
de funcționarea. În baza acestei diagrame puteam vedea clar care sunt avantajele și dezavantajele la unele
tipuri de SGBD.
La acestă diagramă am utilizat un alt tip de relație : relație de generalizare / moștenire .

7
 Fig.4 Interaction

În Fig.4 observăm interacțiunea dintre baza de date , utilizator și aplicația web . Obsevăm că
actorii DB și Web App se află în relație de dependență de actorul Server, deci ei depind de funcționarea
actorului Server.
De asemena observăm și facilitățile pe care le are actorul User : controlul informației, logarea în
sistem ( ce se referă doar la aplicația web ) , de asemenea vizualizarea informației. Use – Case – ul View
DB data la rândul său extinde use – case – urile View DB Data ( adică afișarea informație ce ține
nemijlocit de baza de date , informația despre mărimea, dimensiunile și caracteristicele bazei de date ) și
View Account Data ( adică informația ce se află nemijlocit pe baza de date )

2.2. Diagrama de secvență

În limbajul UML colaborarea între entități se cercetează în aspectul informatv al comunicațiilor ,

adică obiectele care interacționează între ele fac un oarecare schimb de informații . Pentru modelarea
colaborării între obiecte în limbajul UML se utilizează diagramele de interacțiune .

Pentru sistemul nostru informațional vom construi 3 diagrame de secvență .

Fig.1 Interogate DB

8
 În Fig.1 este o diagramă de secvență ce arată interacțiunea dintre User – Database – Server . După
cum observă actorul User dorește să extragă data din baza de date . La rândul său baza de date
“transmite” o solicitate pentru a afișa informați dorită de utilizator. Server la rândul său procesează
informația – adică solicitarea primită – și transmite răspuns bazei de date , ca mai apoi informația
solicitată de utilizator să fie afișată la ecran .
La realizarea acestei au fost utilizate interacțiunile sincrone și asincrone , și, desigur, return pentru
întoarcerea răspunsului.
Fig.2 Connect to DB

În a doua diagramă (Fig.2) se observă clar procesul de conectare cu baza de date . Utilizatorul se
conectează prin intermediul aplicației la baza de date , iar aceasta la rândul ei transmite datele – usename
și password – către server. Acesta prelucrează datele, verifică corectitudinea lor, și transmite răspuns
bazei de date . Iar mai apoi, prin intermediul interfeței ,adică a aplicației, utilizatorul primește mesajul că
conectarea a avut loc cu succes. La final închidem aplicația.

9
 Fig.3 Working Session

În Fig.3 este descrisă modalitate de interogarea DB ,este arătat cum Administratorul extrage
informație de pe baza de dată locală (adică partea care nemijlocit se află pe calculator) și este arătată și
extragerea informației nemijlocit de pe server . Obsevăm cum Administratorul în primul rând începe
sesiunea de lucru , apoi extrage informația din DB locală. Aplicația face conexiunea cu baza de date
locală și solicită informația necesară utilizatorul . Baza de date procesează cererea, transmite răspuns
aplicației ca mai apoi utilizator să vizualizeze la ecran informație.

În mod similar are loc și extragerea informației de pe server ,doar că atunci când se ajunge la
baza de date, aceasta se conectează la server. Serverul procesează informația,transmite răspuns bazei de
date și prin intermediul aplicației utilizatorul vizualizează informația. La final se încheie sesiunea.

2.3. Diagrama de colaborare

Sunt 2 tipuri de diagrame de colaborare:

1. Nivel de exemplu
2. Nivel de specificare

Diagrama de colaborare – nivelul de exemple indică exemplare și legături, roluri în colaborare.

Astfel,prima diagrama nivel de exemplu va reieși din Fig.3 Working Session (diagrama de secvență)

10
 Fig.2.1 Collaboration Diagram

După cum se observă în Fig.2.1 , există legături directe dintre actorul Admin – Application ,
Application – Database și Database – Server . Pe fiecare legătură este specificat mesajul și direcția (relație
sincronă,asincronă, return) . Astfel , diagrama de colaborare nivel de exemplu nu e altceva decât o altă
forma de reprezentare a Fig.3 Working Session (diagrama de secvență)

Fig.2.2. Specification Diagram

După cum observăm în Fig.2.2 colaborarea la nivel de specificare se reprezintă printr-o eclipsă
punctată , și în interios se specifică numele acesteia – în cazul dat Manage Data . Diagrama data defapt e
un caz de utilizare mai particular, simbolul elipsei se unește după cum vedem cu participanții colaborării
– actorul Admin și actorul Database . De asemenea, în această diagramă este specificată o notiță legată la
elipsă pentru a indica specificul colaborării .

11
 2.4. Diagrama claselor

Diagrama de clase se utilizează pentru reprezentarea structurii statice a unui model de sistem în
terminologia claselor programării OO. Diagrama de clase poate reflecta diferite legături între entitățile
domeniului de obiecte și descrie structura lor internă și tipurile de relații.

Fig.1 Users

Diagrma de clasă de mai sus descrie gruparea utilizatorilor( regular_user și admin) , și sunt arătate
clasele de logale la baza de date (LoginDB) și înregistrarea utilizatorilor (RegisterUsers) . Au fost definite
de asemenea atribute fiecărei clase .
Clasa User are așa atribute precum first_name , last_name,password,user_name . Clasa LoginDB
are doar atributele password și user_name. Clasa RegisterUser are atributele :
first_name,last_name,password,user_name,birthday,email și contact_phone.
De asemenea fiecare clasă au un set de operațiuni diferite . Clasa User dispune de operațiunile
precum : login(), logout(), register(), search() . Observăm că clasa Regular_User moștenește aceste
operațiuni, iar clasa Admin moștenește tot acestea operațiuni, plus mai dispune de operațiuni precum :
addToDB ( adăugarea în BD) , addUser(adăugarea utilizatorilor) , deleteFromDB ( ștergerea din
BD),deleteUser(ștergerea utilizatorilo),update(actualizarea în BD )

12
 Fig.2 DB Objects

Diagrama de clasă de mai sus (Fig.2 DB Objects) descrie structura BD / obiectele bazei de date .
În această schema am folosit compoziția ( între clasa Schema și Database , Table și Schema) și agregarea
(între clasele Schema și Package, Package și Functions, Procedure și View) .
Fiecare clasă are atribute ce le descriu, spre exemplu : clasa Functions are atributele :
- id_func – identificatorul unic al funcției
- function_name – denumirea funcției
- data_created – data creării funcției
- package_name – pachetul în care se află funcția
- last_ddl – obiectele BD de obicei conțin informații despre perioada când a fost creată și când a
fost modificată acest obiect. Atributul dat specifică data când ultima oară a fost modificat
obiectul .

13
 Fig.3 Table and View Description

Diagrama din Fig.3 descrie la un nivel mai detaliat structura obiectelor bazelor de date
Table(Tabele) și View(Vederi) . Observăm că clasa Database realizarează interfața IApplication .
De asemenea, în diagrama dată este prezentă relația de compoziție dintre clasele Table și
Database și relația de agregare dintre clasele View și Database.
Se observă de asemenea și relația de generalizare / moștenire . Asfel, clasa Table ca moștenire are
clasele Regular_Table , Temp_Table și Pivot_Table . Fiecare dintre acestea implementează operațiunii
clasei de bază Table, dar de asemenea clasele Temp_Table și Pivot_Table au câte o operațiune specifică
acestori tipuri de tabele.
Pentru clasa View de asemenea sunt 2 clase : Regular_View și Materilized_View.Și acestea de
asemenea implementează operațiunile de bază a clasei View, dar și au operațiuni specifice lor.

Fig.4 Table Structure

14
 La un nivel mai detaliat, studiem structura clasei Table , observăm ce relații se află între ea și
clasele din schemă – compoziție ( Table – Column) ,agregare (Table – Row) . Clasa Column de asemenea
se află în relație de agregare (Column – Foreig-Key , Column – Primary_key , Column – Index ). Clase
Index la rândul ei este în relație de generalizare ( Index – NonUniqueIndex, Index – UniqueIndex)
Pentru fiecare clasă au fost atașate atribute care le descriu.

2.5. Diagrama stărilor

Fig.1 DB Interogation

Diagrama de stări din Fig.1 DB Interogation descrie consecutivitatea de stări posibile de la deschidea
aplicație (SGBD-ului) până la închiderea acestuia . Astfel, diagrama de stări caracterizează
comportamentul elemetelor sistemului modelar în timpul ciclului de viață . Prima stare este starea de
deschidere a aplicație, apoi , pentru a trece în starea 2 se introduce login-ul și parola ( enter username and
password) . Din starea Connecting to DB sunt 2 direcții posibilie :
1. Când apare eroare la conectare și aplicația se închide și se trece la starea finală – Closing App
2. Când conectarea a avut loc cu succes – se trece la starea de New Session
După ce sesiunea a fost pornită , se execută un anumite script ( select, update, delete ,sau alte) și
trecem în starea de interogare a bazei de date . La final se face commit – finisarea tranzacției – și se
ajunge în starea Finish session ,după care trecem în starea finală Closing App și ajungem la punctul final .

15
 Fig.2 Operation with DB

Diagrama din Fig.2 este reprezentarea grafică a stării compuse cu substări concurente depuse .
Avem starea inițială Start session , apoi avem starea Executing care la rândul său conține câteva substări:
substrarea Run script , apoi Call a function care trece în Display Data și a treia substare este Exec
procedure . După ce au finisat toate aceste substări se ajunge la starea finală Finish session .

2.6. Diagrama activităților

Fig.3 Activity diagram – interogate DB

În diagrama din Fig.3 avem descrisă diagrama de activitate asupra lucrului cu informația din baza
de date. Prima ”activitate” este activitate de conectare la baza de date – Connect to Database - după
acesta urmează un bloc de decizie , pentru a verifica dacă e a fost făcută conectarea – is connecting? . În
caz că a aparut o eroare la conectare – error - se întoarce la ramificatorul inițal pentru a putea revenit la
prima activitate – Connect to Database .
Dacă totuși conectarea a avut loc cu succese se începe sesiunea de lucru – start working session –
după care se face un select / se extrag datele la ecran . Aici din nou apare blocul de decizie, pentru a
verifica dacă datele sunt disponibile / dacă datele există în general – is available data ? . În caz că datele
nu există se duce la activitatea Data not exist iar din acest punct se duce spre punctul de final .

16
 În caz că date sunt disponibile – data is available - atunci se merge spre vizualizarea informației –
activitatea view data .
Următoarea etapă este etapa de actualizare a datelor .Avem aici un bloc de decizie pentru a verifica dacă
datele pot fi actualizate – can update ? . Dacă datele nu pot fi actualizate de utilizator,dacă acesta nu are
drept de a actualiza - don’t have priveleges – atunci se ajunge la punctul că apare eroare de actualizare –
Updating error și de aici se trece spre punctul de final – ActivityFinal.
Dacă utilizatorul a putut totuși actualiza informațiile – have priveleges – atunci se vizualizează informația
nou modificată – view new data – și se trece la finisarea sesiunii – Finish session – și apoi se trece spre
puctul de final .

Fig.4 Manage user information

În diagrama din Fig.4 se observă activitatea utilizatorului în baza de date . Avem activitatea
Login după care urmează un bloc de decizie pentru a verifica dacă utilizatorul logat este sau nu
administrator – is admin ? În caz că acesta nu e administrator – no - se trece la View personal data .
În cazul când utilizatorul logat este administrator – yes – atunci observăm că este un nod de tip
fork – orizontal fork . De la aceasta se pornește mai multe activități – add user , modify user , delete
user , give priveleges, revoke acces - observăm că toate aceste activități sunt disponibile doar
administratorului .
Toate aceste activități , împreună cu activitatea destinată utilizatorului simplu – View personal
data – trec printr-un fork vertical în activitatea Logout după care se trece la Final

17
 2.7. Diagrama componentelor

Pentru reprezentarea entităților fizice în limbajul UML se utilizează componenta . Componenta

realizează un set de interfețe și desemnează elementele reprezentării fizice a unui model .

Fig.1. Component Diagram – DB Object

Pentru reprezentarea entităților fizice în limbajul UML se utilizează componenta . Componenta

realizează un set de interfețe și desemnează elementele reprezentării fizice a unui model .

În diagrama din Fig.1 se vede reprezentarea componentelor bazei de date relaționale. Aici vedem
2 componente de bază de la care ”revin” alt componente : componenta Schema Object și componenta
Nonschema Object.
Observăm că Nonschema Object ”conține” alt obiecte a bazei de date : Tablespace , Roles, Users.
Și Schema Object conține deasemenea alte componente : Index, View , Table, Packagei – în bazele de
date aceastea sunt obiectele principale de lucru cu informația.

Fig.2. Component Diagra – Type of DBMS

18
 În Fig.2. este reprezentată diagrama componentelor ce descrie într-o formă mai restrânsă tipurile
bazelor de date .
Observăm că spre componenta Database se pornesc componentele Hierarchical DBMS , Network
DBMS , Relational DBMS , Object Oriented Model . De la componenta Relational DBMS se observă de
asemenea că se pornesc componentele Sql ,MySql,Oracle – exemple de DBMS . Și , de asemenea, de la
componenta Object Oriented Model se pornesc componentele Java și PostgreSQL 9.5(2016)

Fig.3. DBMS Components

În Fig.3. sunt reprezentate componentele unui SGBD . Aici sunt așa componente precum :
- Sofware – setul de programe utilizate pentru controlul și managementul asupra bazei de date . Aici
se includ însăși aplicația SGBS(Microsoft Sql Server, Toad, Sql Developer,etc), aplicația web
pentru accesul datelor.
- Hardware – componentele electronice utilizare pentru vizualivarea bazei de date – calculator sau
un alt dispozitiv conectat la rețea.
- Data – una din cele mai principale componente . Este vorba de însăși informația stocată în baza de
date.
- Procedures – se referă la instrucțiunile și regulele de utilizarea a SGBD-ului , setul de
documentele (ghid de utilizare) ce ajută la lucru cu SGBD-ul
- Query Processor – procesorul de interogări , transformă codul într-un set de instrucțiuni înțelese
de procesor ca mai apoi să se afișeze informația la ecran.
- DB Access Language – este utilizat pentru accesul la baza de date ,pentru adăugarea datelor noi
(insert) , actualizarea informațiilor existente (update) sau retragerea informației la ecran (select).
Cu alte cuvinte , este vorba de setul de operațiuni de manipulare a informației din baza de date.
- DB Engine – serviciu de stocare , procesare și securizare a datelor .Toate tranzațiile sunt
controlate de această componentă .
- DB Manager - component responsabil pentru integritatea datelor – restabilitarea datelor ,etc.

19
 2.8. Diagrama de desfășurare

Fig.1 Deployment Diagrama DB

Diagrama de plasare – deployment diagram - este specifică pentru vizualizarea elementelor și

componenetelor a programului. În diagrama de mai sus sunt prezentate componentele ,exemplare a
programului .
În cazul de mai sus avem 3 noduri cu putere de calcul – nodul PC_User , PC_Admin și Server . De
asemenea avem și componente fără putere de calcul, cu alte cuvinte – echipamente de legătură sau
echipamente periferice ce nu pot funcționa fără nodurile principale. Dintre aceste noduri sunt : nodul
Network – aici poate fi un router, un modem ce formează rețea ; dispozitivele Mouse (șoricelul),
Keyboard (tastatura), System Unic ( blocul de sistem),Monitor(monitorul) . Observăm că fiecare nod
PC_User și PC_Admin au conectare aceste echipamente.
De asemenea , avem integrate și componente în fiecare nod :
- Nodul PC_User conține componentul Browser
- Nodul PC_Admin conține componentele Browser și DBMS(Database Managemnt System)
- Nodul Server conține componentele Database și Web App

20
Concluzie

Proiectul de an la disciplina Analiza și Modelarea Obiect Orientată reprezintă o

experiență interesantă și frumoasă .
Pentru mine , ca student și angajat în câmpul muncii ca inginer programator ,
proiectul de an a fost o șansă bună de a verifica aptidutinile de proiectare . Această
disciplină mi-a permis să înțeleg proiectarea sistemelor mai bine și să cunosc mai detaliat
ce stă defapt la baza proiectării.
Diagrama realizate în cadrul acestui proiect reprezintă un avantaj aparte . Astfel ,
din punct de vedere vizual am înțeles mai bine cum trebuie proiectat un sistem pentru ca
acesta să ofere toate facilitățile puse ca scop.
Cunoștințele obținute în cadrul elaborării acestui proiect îmi vor fi de folos atât la
următoarele disciplini,cât și în cadrul muncii.

21
Bibliografie

1. https://sparxsystems.com/products/ea/history.html - informații referitoare la

aplicația folosită .
2. www.google.com – informații teoretice despre diagrame

3. www.wikipedia.com – informații referitoare la domeniul ales.

22