Curs 7 Page 1 of 4

Analiza si gestiunea sistemelor informatice complexe

Curs 7
Arhitectura sistemelor informatice. Obiecte persistente

Arhitectura sistemelor informatice

Modelarea arhitecturii unui sistem informatic priveste trei elemente distincte:

- Tehnologia de dezvoltare: instrumentele necesare pentru construirea aplicatiilor (sisteme de gestiune a bazelor de date, limbaje si medii de
programare, controlul codului sursa, gestiune configuratii, instalare etc). De obicei acestea sunt cunoscute (stabilite) de la inceputul proiectului. In aceasta
faza se realizeaza o validare a corectitudinii si eventual se fac anumite modificari (daca este posibil resurse umane si de timp);
- Tehnologia de acces la date: modul de accesare a datelor de catre aplicatie (inclusive tehnologia de replicare si infrastructura de acces la
date);
- Tehnologia de proiectare a aplicatiei: modul de segmentare a aplicatiei, strategii de impartire pe nivele, gestionarea nivelelor.

Pe masura ce se cunosc cerintele aceste trei arhitecturi se rafineaza si se stabileste configuratia potrivita, rezultatul purtand numele de arhitectura de
executie.

Una dintre cele mai importante operatii care se realizeaza in etapa de proiectare a arhitecturii unui sistem informatic este aceea de separare a
serviciilor furnizate de acesta. Pana la aparitia (utilizare pe scara larga) a tehnologiilor client-server si a Internetului, aplicatiile in general nu erau proiectate in
spiritul separarii serviciilor ce le ofereau.

O aplicatie o putem privi ca fiind structurata pe 3 nivele: nivelul de prezentare, de logic a aplicaiei (de business) si de date (a nu se face confuzie cu
tipurile de clase: entitate, control, interfata). Aceste nivele induc i dou tipuri de independen logic: modificarea unui nivel nu trebuie s afecteze
modificri ale altor nivele.

Nivelul (servicii) de prezentare: n general este vorba de o prezentare grafic sau ia forma unor rapoarte. Separarea serviciilor de prezentare de cele
de logic a aplicaiei permite modificarea interfeei cu utilizatorul cu eforturi reduse (ex. implementarea unei interfee web pentru o aplicaie existent)
Implementare: prezentarea datelor, acceptarea datelor, interfata grafica cu utilizatorul
Obiective: uurin n utilizare, interaciune natural i intuitiv cu utilizatorul, timpi rapizi de rspuns

Nivelul de logic a aplicaiei: reprezint cel mai dinamic nivel al unui sistem informatic, deoarece regulile de logic a aplicaiei i funcionalitatea se
modific mult mai des. Izolarea de celelalte nivele face ca impactul implementrii unor modificri s fie redus. n msura n care este posibil, nivelul de
logic trebuie s nu conin elemente legate de interfaa utilizator sau acces la baza de date.
Implementare: reguli de logic a aplicaiei, controlul fluxului n aplicaie, impunerea unor restricii pentru pstrarea consistenei datelor
Obiective: impunerea rigid a regulilor de logic, conservarea investiiei n cod surs, reducerea costurilor de ntreinere

http://lci.cs.ubbcluj.ro/~tzutzu/Didactic/AnalizaGestSisteme/Curs7.htm 3/2/03
PDF created with FinePrint pdfFactory trial version http://www.pdffactory.com
 Curs 7 Page 2 of 4

Nivelul de date: este cel mai static nivel, deoarece structurile de date i relaia dintre acestea se modific rar.
Implementare: robustee n stocarea/interogarea datelor, accesul la Sitemul de Gestiune a Bazelor de Date, controlul concurenei
Obiective: baza de date consistent i sigur, partajarea informaiilor, timpi rapizi de rspuns

Cele trei nivele menionate sunt nivele logice. Aplicaiile care au o astfel de segmentare poart denumirea de aplicaii cu arhitectur pe 3 nivele (3-
tier achitecture).

n general, acestea se implementeaz n 2 nivele fizice: calculator client (nivelele de prezentare i logic) i server de date (nivelul de date). Aceast
soluie a fost utilizat iniial pentru aplicaii client/server distribuite. Implementarea nivelelor logice individual, ca nivele fizice separate (client nivel de
prezentare, server de aplicatie nivel de logic, server de date nivel de date) este impusa de urmatoarele aspecte:

- distribuia softului ctre clieni atunci cnd pri ale aplicaiei se modific i configurarea aplicaiei pentru diveri noi clieni (se refer la
componentele de acces la baza de date i dificultatea instalrii i configurrii dispozitivelor ODBS pe maini multiple);

- in funcie de tehnologia bazelor de date, costurile se ridic substanial dac fiecare staie de lucru necesit licen de acces la baza de
date;

- scderea performanei atunci cand anumite calcule complexe sunt realizate pe calculatoare client care au resurse reduse.

Practic ns, arhitectura fizic a unei aplicaie poate fi impartita pe mai multe nivele (N-tier architecture) -> mai multe server de date i servere de
aplicaie.

Exist mai multe strategii de proiectare optim i flexibil a unei aplicaii. Minimum necesar pentru o aplicaie care se dorete s nu cunoasc
probleme majore la modific pe o perioad de 1-2 ani este implementarea celor trei nivele menionate. Aceast abordare reprezint minimul necesar,
deoarece exist abordri care rafineaz fiecare nivel n parte, distingnd mai multe subnivele.

Nivelul de logic a aplicaiei conine dou sub-nivele:

- nivelul contextului aplicaiei : interacioneaz cu interfaa utilizator permit filtrarea i consistena informaiilor pe msur ce ele sunt introduse n
sistem (ex. o valoare a unui cmp limiteaz valorile ce pot fi introduse ntr-un alt cmp).
- nivelul regulilor de logic: sunt legate de reguli de logic convenionale (tradiionale) (ex. nr. de credite inferior unui anumit numr nu permite
promovarea unui student n anul urmtor)

Nivelul de date conine trei sub-nivele:

- translatarea datelor: traducerea unei cereri logice (ca adugare, tergere, modificare) ntr-un limbaj care este compatibil cu modalitatea de
stocare a datelor (SQL).
- accesul la date: executarea cererii folosind funcii API (interfa nativ a bazei de date, ADO cu OLE/DB sau driver ODBC).
- baza de date se refer la tehnologia bazei de date (SQL Server, Oracle, Access)

Nivelele determinate mai sus se pot constitui in componente distincte ale sistemului informatic. Determinarea mecanismului de comunicare ntre nivele
se realizeaz rspunznd la urmtoarele ntrebri:

o ce tehnologie de comunicare ntre-procese (IPC) va fi utilizat? Mecanismul IPC poate fi gestionat de diverse tehnologii, ca RPC sau

http://lci.cs.ubbcluj.ro/~tzutzu/Didactic/AnalizaGestSisteme/Curs7.htm 3/2/03
PDF created with FinePrint pdfFactory trial version http://www.pdffactory.com
 Curs 7 Page 3 of 4

CORBA (Common Object Request Broker Architecture), COM sau DCOM.

o ce mecanism va fi utilizat pentru comunicarea intre nivele atunci cnd un IPC este utilizat?

Obiecte persistente

Etapa de proiectare a unui sistem informatic presupune si determinarea obiectelor persistente, adica a acelor obiect ce se vor pastra intre doua
executii ale unei aplicatii. Determinarea acestor obiecte se realizeaza pe baza diagramei de clase, dupa care ele sunt translatate intr-un model relational
ce va sta la baza proiectarii bazei de date. Cea mai simpl i uoar metod de translatare a claselor n tabele ale unei baze de date este asocierea 1:1 a
claselor cu tabele. Aceast metod nu este ns recomandat deoarece pot aprea urmtoarele probleme:
- prea multe tabele: n general din modelele OO pot rezulta, prin aceast metod, mai multe tabele dect este necesar
- prea multe operaii de conectare (join): multe tabele -> mai multe operaii de join SQL pentru regsirea datelor (v. relaiile de 1:1)
- tabele ignorate: relaiile de asociere n:m se implementeaz prin intermediul unei tabele de legtur (curs-studenti). Clasele asociere reduc aceste
probleme dar ele sunt n puine cazuri modelate.
-tratarea necorespunztoare a motenirii
- de-normalizarea datelor: duplicarea acelorai date n mai multe tabele (apare n special din cauza claselor care modeleaz necesiti unice de
raportare).

Cazurile de utilizare/diagramele de interaciune pot da anumite informatii legate de frecvena de utilizare/interogare a anumitor date -> ncercare de
proiectare a BD astfel nct aceste operaii s se realizeze ntr-un minim de timp.

nainte de a transforma clasele n entiti relaionate trebuie s rspundem la ntrebarea dac necesit s fie persistent sau nu? n Rational Rose
pentru fiecare clas se permite specificarea (n tab-ul Detail) dac o clas este persistent sau temporar.

Transformarea asocierilor simple:

- asocieri 1:1 -> dou tabele (dac este asociere 1 0..1) sau o tabel cnd este 1:1

- asocieri 1:n -> dou tabele. Cheia unei tabele (1) este cheie strin pentru tabela corespunztoare lui n.

- asocieri m:n. Dou tabele plus o tabel de legtur (tablea de intersectie). Cheia tabelei de legtur poate fi un surogat, sau poate fi compus
din cheile principale ale celorlalte dou tabele (ex. salariat patron)

Transformarea relatiei de motenire:

Exista trei variante de transformare in tabele a unei perechi super-clasa / sub-clasa

1. Se creaza cate o tabel pentru fiecare clas i un view SQL pentru fiecare pereche superclas/subclas
2. Se creaz o singura tabel (corespunzatoare superclasei) i se de-normalizeaz toate coloanele de inf. din subclase n tabela superclasei. Implic
modificri ale tabelei pentru urmtoarele subclasri, i conine spaii moarte -> poate afecta performana accesului la date. Se mai adaug un
cmp (i eventual o tabel) special care precizeaz tipul unei inregistrari memorate in tabela.

http://lci.cs.ubbcluj.ro/~tzutzu/Didactic/AnalizaGestSisteme/Curs7.htm 3/2/03
PDF created with FinePrint pdfFactory trial version http://www.pdffactory.com
 Curs 7 Page 4 of 4

3. Se creaz cate o tabelapentru fiecare subclas i se de-normalizeaz atributele superclasei n fiecare subclas. Dac se modific superclasa, trebuie
s se modifice toate subclasele.

In cazul in care numarul nregistrrilor este limitat in super-clasa si sub-clase atunci prima varianta este cea mai potrivita (performanta nu este grav
afectata iar flexibilitatea este maxima). Dac numarul atributelor n super-clas este mic n comparaie cu sub-clasa atunci varianta 3 este una
acceptabila. In fine, in cazul in care cantitatea de date din subclase este mic atunci varianta 2 reprezinta o solutie de compromis acceptabila deoarece
performana de acces la date este cea mai bun insa cu un potenial redus de flexibilitate.

Evident, oricare va fi decizia de transaformare a unei relatii de mostenire, nivelul de logica a aplicatiei nu va fi afectat, deoarece aici se vor vedea
entitile asa cum sunt n diagrama de clase. Doar frazele SQL (nivelul de translatare a cererilor de la nivelul de logica a aplicatiei) vor fi afectate.

Transformarea agregrii i compunerii:

- in general, se transforma relaii standard inter tabele;

- relaiile de agregare se implementeaz n tabele separate fr tergere n cascad. De obicei in aceste cazuri se formeaz multe relaii 1:1;
- relatiile de compunere sunt implementate aproape ntotdeauna ca o singur tabela. Atunci cnd se alege varianta cu mai multe tabele, atunci
trebuie implementat opinea de tergere n cascad.

Asocierile reflexive se transforma in relaii recursive. Acestea sunt dificil de ntreinut, mai ales in cazul asocierilor bidirecionale care au asociate
constrngeri de integritate.

Cheile asociate tabelelor pot fi naturale sau surogat, generate de automat de catre sistemul de gestiune al bazelor de date. Avantaje pentru a doua
abordare:
- toate cheile din BD sunt de acelasi tip viteza in join-uri i consisten;
- join-uri limitate la un singur cmp (n locul unei chei compuse);
-necesarul de stocare este redus.

Dezavantajele folosirii Rational Rose pentru generarea de tabele din diagramele de clase:
- daca anumite atribute nu se genereaz (din cauza unor erori), atunci trebuie fcut adugarea manual;
- nu se genereaz tabele de intersecie pentru asocieri n:m (doar dac este o clas asociere);
- pentru dou clase A i B aflate ntr-o asociere 1:n bidirecional se genereaz 2 relaii distincte intre tabelele corespunzatoare claselor A si B;
- nu suport atribute tranzitorii (calcule, etc). Ele vor fi generate n tabele.

http://lci.cs.ubbcluj.ro/~tzutzu/Didactic/AnalizaGestSisteme/Curs7.htm 3/2/03
PDF created with FinePrint pdfFactory trial version http://www.pdffactory.com