Analiza si gestiunea sistemelor informatice complexe
Curs 7

Arhitectura sistemelor informatice. Obiecte persistente

Back Up Next

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 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?

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 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

  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ă modificări ale tabelei pentru următoarele subclasări, şi conţine spaţii ‘moarte’ -> poate afecta performanţa accesului la date. Se mai adaugă un câmp (şi eventual o tabelă) special care precizează tipul unei inregistrari memorate in tabela.
  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 î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.

 

 

Back Up Next