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 aplicaţiei (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 modificări 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 aplicaţiei permite modificarea interfeţei cu utilizatorul cu
eforturi reduse (ex. implementarea unei interfeţe web pentru o aplicaţie
existentă)
Implementare: prezentarea datelor, acceptarea
datelor, interfata grafica cu utilizatorul
Obiective: uşurinţă în utilizare, interacţiune
naturală şi intuitivă cu utilizatorul, timpi rapizi de răspuns
Nivelul de logică a aplicaţiei: reprezintă cel mai dinamic nivel
al unui sistem informatic, deoarece regulile de logică a aplicaţiei şi
funcţionalitatea se modifică mult mai des.
‘Izolarea’ de celelalte nivele face ca impactul implementării unor
modificări să fie redus. În măsura
în care este posibil, nivelul de logică trebuie să nu conţină elemente legate de
interfaţa utilizator sau acces la baza de date.
Implementare: reguli de logică a aplicaţiei,
controlul fluxului în aplicaţie, impunerea unor restricţii pentru păstrarea
consistenţei datelor
Obiective: impunerea rigidă a regulilor de logică,
conservarea investiţiei în cod sursă, reducerea costurilor de
întreţinere
Nivelul de date: este cel mai static nivel, deoarece structurile
de date şi relaţia dintre acestea se modifică rar.
Implementare: robusteţe în stocarea/interogarea datelor, accesul
la Sitemul de Gestiune a Bazelor de Date, controlul concurenţei
Obiective: baza de date consistentă şi sigură,
partajarea informaţiilor, timpi rapizi de răspuns
Cele trei nivele menţionate sunt nivele logice. Aplicaţiile care au o astfel de segmentare poartă denumirea de aplicaţii 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ă soluţie a fost utilizată iniţial pentru aplicaţii 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:
- distribuţia softului către clienţi atunci când părţi ale aplicaţiei se modifică şi configurarea aplicaţiei pentru diverşi noi clienţi (se referă la componentele de acces la baza de date şi dificultatea instalării şi configurării dispozitivelor ODBS pe maşini multiple);
- in funcţie de tehnologia bazelor de date, costurile se ridică substanţial dacă fiecare staţie de lucru necesită licenţă de acces la baza de date;
- scăderea performanţei atunci cand anumite calcule complexe sunt realizate pe calculatoare client care au resurse reduse.
Practic însă, arhitectura fizică a unei aplicaţie poate fi impartita pe mai multe nivele (N-tier architecture) -> mai multe server de date şi servere de aplicaţie.
Există mai multe strategii de proiectare optimă şi flexibilă a unei aplicaţii. Minimum necesar pentru o aplicaţie care se doreşte să nu cunoască probleme majore la modifică pe o perioadă de 1-2 ani este implementarea celor trei nivele menţionate. Această abordare reprezintă minimul necesar, deoarece există abordări care rafinează fiecare nivel în parte, distingând mai multe subnivele.
Nivelul
de logică a aplicaţiei conţine două sub-nivele:
-
nivelul contextului aplicaţiei : interacţionează cu interfaţa
utilizator permit filtrarea şi consistenţa informaţiilor pe măsură ce ele sunt
introduse în sistem (ex. o valoare a unui câmp limitează valorile ce pot fi
introduse într-un alt câmp).
-
nivelul regulilor de logică:
sunt legate de reguli de logică convenţionale (tradiţionale) (ex. nr. de
credite inferior unui anumit număr nu permite promovarea unui student în anul
următor)
Nivelul
de date conţine trei sub-nivele:
-
translatarea datelor: traducerea unei cereri logice (ca adăugare,
ştergere, modificare) într-un limbaj care este compatibil cu modalitatea de
stocare a datelor (SQL).
-
accesul la date: executarea cererii folosind funcţii 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ă răspunzând la următoarele întrebări:
o ce tehnologie de comunicare între-procese (IPC) va fi utilizată? Mecanismul IPC poate fi gestionat de diverse tehnologii, ca RPC sau CORBA (Common Object Request Broker Architecture), COM sau DCOM.
o ce mecanism va fi utilizat pentru comunicarea intre nivele atunci când un IPC este utilizat?
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 uşoară 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 apărea
următoarele probleme:
-
prea multe tabele: în general din modelele OO pot rezulta, prin
această metodă, mai multe tabele decât este necesar
-
prea multe operaţii de conectare (join): multe tabele -> mai
multe operaţii de join SQL pentru regăsirea datelor (v. relaţiile de
1:1)
-
tabele ignorate: relaţiile de asociere n:m se implementează prin
intermediul unei tabele de legătură (curs-studenti). Clasele asociere reduc
aceste probleme dar ele sunt în puţine cazuri modelate.
-tratarea necorespunzătoare a
moştenirii
-
de-normalizarea datelor: duplicarea aceloraşi date în mai multe
tabele (apare în special din cauza claselor care modelează necesităţi unice de
raportare).
Cazurile de utilizare/diagramele de interacţiune pot da anumite informatii legate de frecvenţa de utilizare/interogare a anumitor date -> încercare de proiectare a BD astfel încât aceste operaţii să se realizeze într-un minim de timp.
Înainte de a transforma clasele în entităţi relaţionate trebuie să răspundem 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ă când este 1:1
- asocieri 1:n -> două tabele. Cheia unei tabele (1) este cheie străină pentru tabela corespunzătoare lui n.
- asocieri m:n. Două tabele plus o tabelă de legătură (tablea de intersectie). Cheia tabelei de legătură poate fi un surogat, sau poate fi compusă din cheile principale ale celorlalte două tabele (ex. salariat – patron)
Transformarea relatiei de moştenire:
Exista trei variante de transformare in tabele a unei perechi super-clasa / sub-clasa
In cazul in care numarul înregistrărilor 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 comparaţie 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 performanţa de acces la date este cea mai bună insa cu un potenţial 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 entităţile 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 agregării şi compunerii:
- in
general, se transforma relaţii standard inter
tabele;
-
relaţiile de agregare se implementează în tabele separate fără ştergere
în cascadă. De obicei in aceste cazuri se formează multe relaţii
1:1;
-
relatiile de compunere sunt implementate aproape întotdeauna ca o singură
tabela. Atunci când se alege varianta cu mai multe tabele, atunci trebuie
implementată opţinea de ştergere în cascadă.
Asocierile reflexive se transforma in relaţii recursive. Acestea sunt dificil de întreţinut, mai ales in cazul asocierilor bidirecţionale care au asociate constrângeri 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 câmp (î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 făcută adăugarea
manual;
- nu se generează tabele de intersecţie pentru asocieri n:m (doar dacă este o
clasă
asociere);
-
pentru două clase A şi B aflate într-o asociere 1:n bidirecţională se
generează 2 relaţii distincte intre tabelele corespunzatoare claselor A si
B;
-
nu suportă atribute tranzitorii (calcule, etc). Ele vor fi generate în
tabele.