CAPITOLUL 2.

Complemente

O paradigm e o anumit abordare a procesului de proiectare software, care descrie cum se realizeaz
elemente de proiectare, ce metode, unelte i proceduri se aplic la fiecare faz. n acest capitol vom trata unele
probleme conexe ale ciclului de via al programelor, spre exemplu categoriile mari de metode de analiz i
proiectare, respectiv cele dou paradigme de baz: proiectarea structurat i proiectarea orientat pe obiecte. De
asemenea, vom prezenta nite problematici suplimentare, de folos n activitatea curent: despre module de
program i reguli euristice de modularizare i despre arhitecturi specifice aplicaiilor n reea.

2.1. Metode de analiz i proiectare

Aceste metode trebuie s permit partiionarea problemei ntr-o manier care s structureze detaliile n mod
ierarhic i s permit dezvoltarea reprezentrii sistemului.
Cele mai multe metode sunt dirijate de informaie. Aceasta este caracterizat prin 3 atribute: fluxul datelor,
coninutul datelor i structura acestora. Metodele sunt orientate spre urmrirea cu predilecie a unuia din atribute.
a) O abordare orientat pe fluxul datelor (dataflow) este, de exemplu metoda MASCOT (vezi cap.4).
Acesta este util cnd informatia este prelucrat secvenial i nu exist o structur de date ierarhic. n cadrul
abordrii se consider c informaia este transformat pe msur ce parcurge sistemul. Metoda se folosete mai ales
n controlul proceselor i n analiza numeric.
Schema grafic de reprezentare a fluxului de date se numete diagram de flux de date DFD. Se ntlnesc n
asemenea reprezentri diverse convenii grafice (pentru surse/consumatori de informaie, pentru transformri,
pentru depozite de date i pentru canalele de comunicaie).
b) Metode orientate pe structura datelor -> au urmatoarele caracteristici:
- identific obiecte de date numite entitai sau elemente i operaii asupra acestor obiecte numite aciuni sau
procese ;
- presupun c structura informaiei este ierarhic;
- structura datelor se reprezint folosind secvenele, seleciile i repetiiile pentru elementele de date,
printr-un fel de gramatic;
- pun la dispoziie un set de pai pentru a realiza corespondena ntre structurile de date i structurile de
program.
Aceste modele se aplic la sisteme cu structuri ierarhice de informaie: sisteme de baze de date, aplicaii de
sisteme de operare, aplicaii CAD/CAM.
n cadrul metodei nu se acord mult importan conceptului de modularitate. Un exemplu de aplicare a
metodei este metodologia Warnier-Orr.
Exemplu de diagram de entiti pentru un program care se ocup de vnzri; partea de primire comenzi

Formal sunt asemntoare cu DFD ns cercurile sunt productori sau consumatori nu transformri.
Perechea cerere-rspuns din aceste metodologii se numete tranzacie (e specific bazelor de date).
Pentru dezvoltarea aplicaiei se poate ntocmi diagrama de linii de asamblare (ALD). La fiecare pas din
ALD un element de informaie (spre exemplu informaia dintr-o comand) se reunete cu o procedur pentru a
produce elementul de informaie al pasului urmtor (mai sus n ierarhie).

expeditie


&
proces generare
nota plata

Info. comanda
Nr. comanda


&
&
proces asigurare comanda
proces expeditie

Rezultatele aplicaiei se pot reprezenta prin prototipuri pe hrtie pentru ieirea sistemului.

2.2. Proiectarea orientat pe obiecte

Aceast abordare inverseaz metodologiile funcionale, fragile mai ales la reutilizare (la mici
schimbri ale cerinelor trebuie restructurat masiv ntreg sistemul). O abordare orientat spre obiecte (AOO) se
focalizeaz pe obiectele din domenial aplicaiei, adic entitile independente care modeleaz realitatea. La
aceste obiecte se stabilesc ulterior proceduri de acces. Termenul orientat spre obiecte nseamn organizarea
programului ca o colecie de obiecte, fiecare nglobnd structuri de date i avnd asociat un anumit
comportament. n programarea structurat, structurile de date i comportamentul entitilor nu sunt conectate
dect (relativ) slab.
Tehnicile Programrii Orientate pe obiecte (POO), interconectarea elementelor de date i operaiile de
prelucrare asupra acestora ntr-un mod care modularizeaz nu numai prelucrarea ca n programele structurate ci
i informaia de prelucrat.
Aceast metod aplic explicit trei principii ale ingineriei programrii: - abstractizarea, ascunderea,
modularizarea. Pune la dispoziie un mecanism care permite obinerea celor 3 caracteristici fr complicaii sau
compromisuri.
Comport urmtoarele date:
1. Definirea problemei
2. Dezvoltarea unei strategii pentru implementarea prin program a problemelor din lumea real
3. Formalizeaz strategii prin:
a) identific obiectele i atributele lor
b) identific operaiile care se pot aplica obiectelor
c) stabilete interfaa prin indicarea relaiilor dintre obiecte i operaii
d) decizii asupra problemelor de proiectare n detaliu pentru a furniza o descriere pentru

implementare pentru obiecte.

4. Aplicarea recursiv a pailor 2, 3, 4 pn la ncheierea proiectului.
Este implementat de regul n limbaje precum C++, C# sau JAVA (mai sunt i altele, mai puin
utilizate). Principalele platforme tehnologice din spatele acestor limbaje sunt Microsoft.NET pentru C# i C++
i Eclipse (IBM) pentru JAVA.
Scopul POO este de a mpinge spre utilizator efortul de proiectare dnd posibilitatea unei largi game de
utilizatori de a-i avea propriul software, dezvoltat exact dup propriile necesiti, dar totodat permind
accesul la o gam extrem de larg de elemente de program (ierarhii de clase) foarte bine elaborate i testate,
care implementeaz majoritatea funcionalitilor i comportamentelor dorite de utilizator (deci POO
ncurajeaz puternic reutilizarea).
Dup unii autori, o teorie tiinific (Thomas Kuhn-Structura revoluiilor tiinifice) poate fi privit
ca o paradigm despre modul nostru de a privi lumea. O teorie evolueaz pentru a explica aparentele excepii de
la faptele explicate satisfctor de respectiva teorie, pn se ajunge la un moment de criz, cnd excepiile nu
mai ajung s fie explicate. n aceast situaie, adepii teoriei vechi adaug noi caracteristici eteroclite pentru a
explica excepiile, iar reformatorii, adepii unor teorii noi, construiesc un nou model. Pn cnd noua teorie se
maturizeaz i ajunge s domine, ntre cele dou tabere nu exist un dialog coerent. n aceast perspectiv
adepii tehnicilor OO (TOO) i privesc pe ceilali ca producnd sisteme greu de modificat sau reparat,
concentrndu-se prea insistent pe eficiena programelor, n timp ce tabra cealalt consider c TOO conduc
spre programe mari i lente.
n prezent, TOO s-au maturizat i nu se mai pune problema unui conflict ntre adepii diverselor
paradigme. Fiecare abordare are domeniul su predilect. Astfel, pentru aplicaii care trebuie s fie foarte rapide
se mai scriu programe prin metode altele dect OO. Pe de alt parte, performanele aplicaiilor nu mai depind
semnificativ, relativ la cerine, de aspectele structurale ale programelor, datorit creterii performanelor
sistemelor de calcul. De aceea, dezavantajul codului lent nu mai este important.
ntr-o perspectiv simplificatoare, un program este considerat un sistem alctuit dintr-o cutie neagr
avnd intrri, care sufer transformri, i diverse ieiri. n aceasta abordare, dou programe care traduc identic
intrrile n ieiri, pot fi comparate doar prin alte criterii referitoare la comportamentul programelor, spre
exemplu dup dimensiuni tradiionale ale programelor: corectitudine, tratarea erorilor i excepiilor, eficiena,
portabilitatea i independena de periferice. Exist ns dou dimensiuni de apreciere care nu se refer la
comportare: mentenabilitatea (proprietatea unui program de a fi uor de schimbat pentru a fi eliminate defecte)
i extensibilitatea (proprietatea ca un program s poat fi modificat pentru a trata noi clase de intrri).
Paradigma OO este potrivit pentru a ajuta la mbuntirea celor dou caliti non-comportamentale.
Abordarea orientat pe obiecte (AOO) nu refuz modelul cutiei negre dar reduce granularitatea (fineea
mpririi n cutii negre) de la program la obiect. Obiectele dintr-un program devin ele nsele cutii negre ce
conin informaii i prezint o anumit comportare. Reprezentarea datelor sau comportamentul unui obiect dat
pot fi modificate independent.
n AOO criteriile de comportare a programului sunt doar o parte a criteriilor folosite. Accentul este pus
pe identificarea obiectelor i pe modelarea acestor obiecte cu comportarea lor i cu relaiile ntre ele. O abordare
de felul acesta deplaseaz modelarea comportrii lumii la modelarea obiectelor existente n aceast lume i a
comportrii lor individuale, n sens metafizic clasic (Aristotel). Un programator care implementeaz un
program OO poate determina ct de uor de ntreinut i extins este un program, prin aprecierea izolrii
obiectelor unele de altele i prin aflarea a ce este cerut pentru a aduga un obiect nou.

2.3. Proiectarea structurat

Este metoda "clasic" de programare, bazat pe descompunerea problemei n probleme tot mai simple
(abordarea top-down).
Unii definesc "Proiectarea structurat" ca ansamblul de reguli de proiectare n modul cel mai bun cu
putin pentru componentele din sistem precum i pentru legturile i interdependenele dintre acestea.
Alii prefer s considere c "Proiectarea structurat" const n a decide care componente trebuie
utilizate i n ce mod acestea trebuie conectate pentru a se soluiona o problem bine definit.

2.3.1. Programarea structurat

Proiectarea structurat este strns legat de programarea structurat. Aceasta este un mod specific de
organizare i codificare a programului astfel nct acesta s fie uor de scris, de depanat sau modificat. Ea se
bazeaz pe combinarea unor structuri simple, iterate ntr-un mod logic i clar, ceea ce permite abordarea
eficient a funciilor la orice grad de complexitate. Scopul proiectrii structurate const n stabilirea structurii
programelor n vederea obinerii de programe uor de scris, de depanat i modificat.
Limbajul PASCAL este ideal pentru aceast structurare (cu toate acestea, PASCAL nu mai e aa folosit,
generalizndu-se mai degrab utilizarea limbajului C, chiar i sau cteodat mai ales n companiile care
dezvolt aplicaii pentru sisteme dedicate Continental Automotive sau Alcatel-Lucent). Programarea
structurat pune accent pe analiza funcional, adic pe stabilirea funciilor sistemului i apoi descompunerea
fiecruia, prin abordare top-down.
Iat cteva elemente ale programrii structurate ("reet)" :
- programarea fr instrucie de salt necondiionat;
- programarea de sus n jos -> top-down (aceasta presupune descompunerea unei probleme de sus n
jos, prin nlocuirea fiecrei subprobleme cu mai multe, mai simple, acestea la rndul lor fiind
descompuse mai departe, .a.m.d., pn la nivelul instruciilor)
- controlul complexitii prin teorie i disciplin
- utilizarea n program doar a structurilor de control fundamentale: blocurilor de procesare, decizie i
reunire. Exist chiar o teorem n teoria general a programelor care afirm c orice program poate
fi transpus, prin eventuala introducere a unor variabile, aciuni i teste suplimentare, ntr-o schem
logic structurat (care s conin deci doar structuri de control fundamentale, iar din fiecare bucl
s avem doar o singur ieire).
Abordarea structurat este ntr-un fel modul natural de a gndi inginerete. Unii ingineri software cad
n pcatul ignorrii aspectelor specifice programrii structurate, fiind extrem de preocupai s fie buni
programatori n paradigma POO. Se ajunge la paradoxul c respectivii pot realiza uor programe complexe
orientate pe obiecte dar nu sunt n stare s implementeze un algoritm de calcul care presupune o reprezentare
sub forma unei scheme logice. Pentru a fi un inginer sofware complet, trebuie ca respectivul s i dezvolte
inclusiv abiliti de nelegere structurat a realitii.

2.3.2.

Cuplarea modulelor

Elementele componente ale sistemului de programe se numesc module (v. Modularitatea ca principiu al
IP). Intre elementele componente exist conexiuni. O conexiune este referirea n interiorul unui modul la alt
modul (spre exemplu, prin identificatorul modulului referit).
Modulele de program trebuie s fie interdependente ntr-un grad c mai mic cu putin. Msura acestei
interdependene se numete cuplare. Aceasta exprim gradul n care trebuie cunoscut un modul n vederea
asigurrii unei funcionaliti corecte a modulului interconectat. Conexiunea este minimal dac la apelarea
unui modul i se transmite doar adresa la care rezultatele trebuie returnate. De obicei ntre module exist o
conexiune normal, adic modulul are mai multe intrri, fiecare intrare fiind minimal n raport cu transferul
de date, iar modulul apelat poate s cedeze controlul modulului apelant ntr-un punct oarecare, indicat de
modulul apelant la activare. Implicit, vor exista i conexiuni patologice (altfel dect normale). Acestea cresc
gradul de cuplare i sunt de evitat.
Gradul de cuplare depinde de numrul de argumente transmise, dac acestea sunt date sau comenzi
(acestea din urm produc un cuplaj mai strns deoarece implic decizii n modulul destinatar al comenzii). Nu
ntotdeauna cuplarea scade cu numrul de conexiuni ntre module (spre exemplu un numr mai mic de comenzi
produce un cuplaj mai strns dect un numr mai mare de variabile oarecare).
n practic se impune tendina de cuplare intrare/ieire, cu coninut ct mai redus de comenzi. Astfel,
modulele sunt cuplate ntre ele prin legarea ieirilor modulului apelant la intrrile modulului apelat.
Cuplarea se poate realiza i prin zone comune de date. Aceast metod este de evitat (desigur n
msura n care este posibil) ntruct proasta funcionare a unuia din module afecteaz funcioanrea tuturor
celorlalte. De aceea, dac nu se poate evita utilizarea acestor zone comune, acestea se partiioneaz din punct de
vedere logic n zone mai mici, utilizate de un numr redus de module.

2.3.3. Reguli euristice de proiectare structurat

Aceste principii au rezultat din experien, din observaii empirice (bun-sim tehnic):
a. dimensiunea modulului. Ideal, elementele unui modul de program ar trebui s fie caracterizate de
coeziune funcional, adic acesta s conin elementele necesare realizrii funciei propuse. Practica
arat c majoritatea funciilor pot fi realizate cu module de 20-80 instrucii. Dac numrul de instrucii
este mai mic de 15-20, modulul se include n alt modul.
b. fan-out este mulimea modulelor asupra crora acesta i exercit controlul (deci modulele de la
nivelul ierarhic inferior). De obicei se consider c acesta poate fi maxim 7. Dac crete peste 9 (cnd se
manifest suprtor efectul pancaking plcint, adic distribuire, mprtiere excesiv) se impune
restructurarea programului. La un fan-out sub 3-4 se recomand includerea nivelului ierarhic inferior n
modulul de la nivelul ierarhic superior
c. fan-in este numrul de module ce utilizeaz un modul dat. Acesta trebuie corelat cu dimensiunea
modulului n vederea optimizrii raportului modularizare/timp de execuie.
d. relaiile dintre intrri i comenzi se recomand a se crea sisteme n care nu exist module la nivelul
ierarhic inferior care condiioneaz activitatea unui modul la nivelul ierarhic superior.
Dac apar astfel de situaii, trebuie astfel restructurat sistemul nct elementele de decizie s avanseze n
ierarhia modulelor pentru a se putea respecta regula enunat.

2.4.

Modele arhitecturale. Modelul Client/Server

Toate organizaiile din ziua de azi, guvernamentale, economice i majoritatea ntreprinderilor, mari sau
mici, recunosc rolul central pe care aplicaiile software l au n cadrul lor, aplicaiile avnd rolul reducerii
costurilor i mbuntirii serviciilor fat de competiie. Aceast dezvoltare i necesitatea utilizrii pe o arie
mare a unor date de interes comun a dus la apariia, utilizarea i proiectarea modelului Client/Server, care ofer
date distribuite, portabilitate ntre platforme i un acces standardizat la resurse.
Termenul de Client/Server provine de la metoda tradiional de accesare a unui computer central numit
server de ctre computere aflate la distan sau clienti intr-o infrastructur de reea. Severele utilizeaz baze de
date relaionale n stocarea i ntreinerea datelor ntre care exist referine. Aceste referine sunt meninute
printr-o tehnologie denumit integritate referenial (referential integrity) care ofer mecanisme care acioneaz
asupra datelor (trigger) i proceduri de stocare (stored procedure).
Acest model este o combinaie a trei tehnologii: sistemul relaional de management al bazelor de date
(DBMS), reeaua i interfata client (bazat pe GUI/PC). Fiecare element contribuie n funcionarea platformei
avnd rolul su, dar independent n execuia funciilor sale.
Foarte mult lume consider clientul i serverul ca fiind dou entiti hardware, dar de fapt sunt entiti
software. Trebuie neles c modelul Client/Server implic o entitate software (clientul) care efectueaz cereri,
acestea fiind ndeplinite de o alt entitate software (serverul). Clientul este cel ce transmite o cerere server-ului,
acesta o interpreteaz i apoi o efectueaz. Pentru a putea ndeplini cererea serverul poate referi o surs de
informaie (baze de date), s efectueze procesri asupra datelor, s controleze periferice sau s efectueze cereri
adiionale altor servere. n foarte multe arhitecturi, un client poate face cereri la multiple servere i un server
poate deservi mai multi clieni.
Relaia ntre client i server este una de comand/control, clientul iniiaz cererea i serverul este cel ce
o ndeplineste transmind rezultatul clientului, aplicaia fiind procesat prin divizarea ei ntre cele dou entiti
iar transferul de date este bidirectional. Un server nu iniializeaz niciodat un dialog cu clienii. Clientul poate
funciona pe un server hardware i s efectueze cereri de la un server care ruleaz pe un alt server hardware sau
pe un PC sau clientul i serverul pot funciona pe acelasi computer.
Spre deosebire de un sistem file/server n care datele sunt aduse de pe file server pentru a fi procesate pe
o masin local n acest sistem comenzile sunt transmise asupra bazelor de date localizate pe server, rezultatul
fiind transmis napoi clientului pentru a fi vizualizat.

Arhitectura afecteaz toate aspectele software, ea trebuie s ia n considerare complexitatea aplicaiei,

nivelul de integrare i interfaare cerut, numrul utilizatorilor, rspndirea lor geografic natura reelelor i toate
tipurile de tranzacii necesare nainte de a decide tipul arhitecturii.
De asemenea alegerea arhitecturii afecteaz timpul de dezvoltare, flexibilitatea precum i ntretinerea
aplicaiei. La majoritatea aplicatiilor end user se urmreste: prezentare, procesare i date. Arhitecturile
Client/Server definesc cum aceste trei componente sunt mprite intre entitile software i distribuite n reea,
exist o varietate de moduri cum pot fii divizate i implementate, utilizarea unor astfel de arhitecturi putnd
aduce multe beneficii n viitor companiei permitnd adaptarea la diferite standarde i tehnologii.

Cteva din caracteristicile acestei arhitecturi sunt:

Centralizarea informaiei - ntr-un astfel de mediu , datele sunt stocate pe un server central i exista un singur
punct de control care administreaz cererile aplicaiilor i platformelor. Aceste servere de baze de
date utilizeaz un sistem de management al bazelor de date (DBMS) pentru a defini, stoca i
manipula date .Serverul este generic; programatorii neavnd nevoie s cunoasc un limbaj anume
pentru a accesa date. Utiliznd tehnicile de identificare o organizaie poate crea magazii de date de
la diferite servere distribuite n diferite zone geografice .Aceasta tehnic maximizeaz
performantele fr a compromite modelul centralizat i reduce probabilitatea existenei de date
redundante n aplicaii.
Serverul procesor central - prelund acest avantaj , organizaiile pot reduce procesarea redundant prin
utilizarea procedurilor trigger i de stocare. Server-ul este orientat n procese standard ca : meninerea unor
reguli, validri, i referine de integritate iar prin intermediul funciilor de stocare pe un server comun datele pot
fi manipulate corect din punct de vedere logic i viabile pentru o varietate de limbaje i unelte ale lor.
Performan - serverul este un computer dedicat s proceseze un set limitat de cereri de la clienti. Singura sa
functie este s proceseze cererile asupra bazelor sale de date. SQL ofer facilitti eficient de
utilizare a traficului in reea deoarece doar subseturi ale datelor sunt transmise n reea , n plus
serverele i DBMS sunt desemnate s gestioneze baze de date masive fr o degradare simtitoare a
performantelor.
Securitate - serverele ce lucreaz pe platforme ca UNIX, Linux , Windows sau altele pot oferi o mai mare
securitate pentru managementul bazelor de date in comparaie cu file server-ele standard.
Mecanismele de duplexing, mirroring i copiere permise administratorilor asigur evitarea
dezastrelor, de asemenea aceste baze de date permit definirea de useri i parole care permit
evitarea accesului unor persoane neautorizate.
Referitor la costurile unor astfel de arhitecturi, server-ele sunt cele ce necesit procesoare rapide,
memorie, hard disc-uri mari i un sistem de operare special. Licentierea, instalarea i ntretinerea unor sisteme
ca Oracle, Sybase sau Informix necesit sute de mii de Euro iar dezvoltarea unor aplicaii necesit memorie,
masini noi i noi sisteme de operare. Cu toate acestea n prezent multe organizatii s-au acomodat foarte usor

acestui mediu client/server care ofer o excelent infrastructur pentru a asigura informatie organizatiei
asigurnd integritate, vitez i securitate.
Cele mai populare tipuri de arhitecturi sunt cu doua entiti(two-tier) i cu trei(three-tier).
Arhitectura two-tier
n aceast implementare, cele trei componente ale unei aplicaii (prezentare, procesare i date) sunt
divizate ntre dou entiti (tiers): codul aplicatiei client i baza de date server. O aplicatie client dezvolt un
limbaj i un mecanism de interschimb pentru a transmite cererea server-ului. Prezentarea este detinut n
exclusivitate de client, procesarea este mprtit ntre client i server i datele sunt stocate i accesate de pe
server. PC-ul client si asum ntreaga responsabilitate a functionrii logice a aplicatiei, timp n care motorul
bazei de date verific integritatea. ntr-o astfel de topologie motorul datelor (data engine) este cel ce proceseaz
cererile clientului, limbajul utilizat fiind o form a SQL, transmiterea unei cereri presupune c aplicatia client s
cunoasc sintaxa serverului sau aceasta s fie tradus printr-o aplicatie (API), totodat s se cunoasc serverul,
cum sunt organizate datele i denumirea lor. Datele transmise clientului pot fi manipulate de acesta cum
doreste, datele de pe server fiind centralizate. Aceste medii detin o varietate de structuri de date, totodat aceste
arhitecturi bine n medii eterogene, aplicatia client detinnd controlul orice modificare care apare n cadrul unui
sistem ducnd doar la modificarea aplicatiei client.
Sistemul de securitate ntr-un astfel de mediu este complicat deoarece un user trebuie s detin parole
pentru fiecare server SQL, iar cresterea utilizatorilor poate duce la compromiterea securittii bazelor aflate pe
server. n prezent majoritatea aplicaiilor client/server sunt proiectate s lucreze cu produse middleware care
duc la cresterea securittii, ele detinnd unelte de acces la date.

Arhitectura three-tier
Aceast arhitectur a aprut datorit limitrilor arhitecturii precedente, ea aduce ca noutate separarea
prezentrii, procesrii i datelor n entiti (tiers) software distincte. Aceleasi tipuri de unelte care n arhitectura
precedent erau utilizate pentru prezentare, acum ele sunt dedicate doar pentru prezentare.
Cnd clientul solicit o cerere pentru acces la date sau o procesare a datelor, cererea se face la nivelul de
mijloc care este un server. Acest nivel poate efectua procesri de date sau cereri asemeni unui client la alte
servere. Serverele din nivelul mijlociu pot fi multi-treaded i pot fi accesate de clienti multipli, asemeni unei
aplicaii separate. Sistemele three-tier pot fi implementate utiliznd o varietate de tehnologii, mecanismul de
cerere al clientului de la server n majoritatea sistemelor este utilizat apelul procedurilor remote(RPC). Apelul
unor astfel de proceduri de ctre client asigur sistemului o flexibilitate foarte mare n comparaie cu apelurile
SQL efectuate de client n arhitectura precedent, aceasta datorit faptului n care parametrii necesari cererii
efectuate de client sunt foarte usor transmise i specificatiile structurilor de date care preiau datele primite (if
any), acest lucru permitnd organizatiilor sau structurilor back-end (aflate pe servere) s poat s-si modifice
configurrile n sistem, datele s poat fi organizate ierarhic, relational sau obiectual permind firmelor s
simplifice trecerea la noi tehnologii legate de organizarea bazelor de date, fr a fi nevoie de modificri la
nivelul aplicaiei client.
O exemplificare a acestei abordri este prezentat n figura urmtoare:

De regul, cele 3 nivele sunt stratificare astfel: prezentare (pentru interaciunea cu clienii), logica
aplicaiei (business logic), respectiv acces la date. n figura umtoare, sunt exemplificate i posibile tehnologii
aferente fiecrui nivel:

La nivelele de acces la date i de logic, de fapt pot coexista mai multe servere (pentru sisteme
complexe, cu ncrcare mare), aa cum se prezint n figura urmtoare:

Un alt avantaj al acestei arhitecturi este acela c avnd entiti software separate (acces la date, respectiv
logica aplicaiei) se poate realiza o alocare flexibil a resurselor. Entitile mijlocii (servere) pot fi alocate
dinamic i repartizate n funcie de necesittile firmei. Traficul de reea este redus avnd server-le nivelului
mijlociu, prelund date de la structuri precise nainte s le distribuie la clienti n reea, PC-urile client fiind
dedicate doar prezentrii, memoria i discurile fiind reduse.
Din punct de vedere al dezvoltrii software modularitatea ofer posibilitatea introducerii simple a unor
noi module, precum i reutilizarea acestora n aplicaii asemntoare, astfel reducndu-se costurile.
n concluzie aceast arhitectur ofer o via lung aplicaiilor, indiferent de modificrile aprute n
afaceri, cod reutilizabil, ntreinere uoara i uurin n migrarea ctre noi platforme server i medii.

2.5. Middleware
2.5.1. Definiie i obiectiv
Sub denumirea de middleware (marf din mijloc) se nelege un software de conectivitate care const dintr-un
set de servicii care permit rularea proceselor multiple pe una sau mai multe echipamente/maini n vederea
interaciunii de-a lungul unei reele. Middleware este esenial pentru procesul de migrare de pe aplicaii de tip
mainframe ctre aplicaii de tip client/server i pentru comunicarea de-a lungul platformelor eterogene. Aceast
tehnologie s-a dezvoltat n anii 90 pentru a asigura interoperabilitate n procesul de trecere la arhitecturi de tip
client/server.
Cele mai cunoscute iniiative n middleware sunt:
Distributed Computing Environment (DCE) de la Open Software Foundation's Object Management Group
Common Object Request Broker Architecture (CORBA),
COM/DCOM, Microsoft (Component Object Model (COM), DCOM, and Related Capabilities)

2.5.2. Descriere
Serviciile middleware sunt ansambluri de aplicaii software distribuite care fac legtura ntre aplicaii i
sistemul de operare i serviciile de reea ntr-un nod al reelei.

Utilizarea Middleware
Serviciile middleware furnizeaz un set de Application Programming Interfaces (API) care ofer o
funcionalitate mai mare dect sistemul de operare i serviciile de reea, asigurnd
ca o aplicaie s apar plasat transparent n reea, putnd interaciona cu o alt aplicaie sau serviciu
ca aplicaiile s fie disponibile i sigure
ca o aplicaie s fie scalabil, dar fr a-i pierde funcionalitatea
Middleware poate fi ntlnit sub urmtoarele forme:
monitorizri ale tranzaciilor de procesare (TP, Transaction Processing Monitor Technology) furnizeaz
instrumente i medii de dezvoltare i punere n practic a aplicaiilor distribuite;
apeluri de proceduri la distan (RPC, Remote Procedure Call) permite ca logica unei aplicaii s fie
distribuit de-a lungul reelei. Logica programelor pe sisteme aflate la distan poate fi executat simplu
doar prin apelarea unei rutine;
Middleware orientat pe mesaje (MOM, Message-Oriented Middleware) furnizeaz schimbul de date
program-ctre-program, permind crearea aplicaiilor distribuite. MOM este asemntor e-mail-ului prin
faptul c este asincron i necesit ca la recepia mesajelor s fie interpretat nelesul acestora i s aib loc
aciunile potrivite;
Intermediari de cerere obiect (ORBs, Object Request Brokers) permit ca obiectele cuprinse ntr-o aplicaie
s fie distribuite i accesibile de-a lungul reelelor eterogene.
Midlleware se bazeaz pe tehnologii informaionale moderne cum sunt XML, SOAP, servicii Web i SOA. Este
o parte din software care conecteaz dou sau mai multe aplicaii software astfel nct acestea s fac schimb
de date.
Programatorii nu vor trebui s nvee noi limbaje de programare pentru a lucra cu tehnologia middleware, ci pot
folosi limbajele cu care sunt familiarizai, cum sunt C++ sau Java. Exist 3 modaliti principale prin care se
poate folosi middleware cu limbajele existente. Prima este cea n care sistemul care folosete middleware
furnizeaz o bibliotec de funcii care vor fi apelate pentru a utiliza middleware. O a doua modalitate const n
utilizarea unui limbaj de definire a unei interfee externe (IDL, Interface Definition Language); n aceast
abordare, fiierul IDL descrie interfaa componentei aflate la distan i se utilizeaz o mapare de la IDL la
limbajul de programare pentru codul utilizat de ctre programator. Cea de a treia modalitate const n
posibilitatea ca limbajul i sistemul runtime s asigure suportul nativ al distribuiei; spre exemplu, RMI
(Remote Method Invocation) din Java.

2.5.3. Utilizare
Serviciile middleware rezolv problemele de conectare i interoperabilitate n multe aplicaii, dar nu sunt un
panaceu. Exist limitri ale punerii n practic, datorate distanei dintre principii i punerea lor n practic.
Multe servicii middleware folosesc implementri de firm, determinnd dependena aplicaiilor de produsele
unui singur vnztor. Numrul mare de servicii middleware reprezint n sine o barier n utilizarea acestora.
Pentru a avea un mediu de prelucrare simplu de utilizat dezvoltatorii trebuie s selecteze un numr redus de
servicii care s satisfac funcionalitatea. Chiar dac serviciile middleware cresc gradul de abstractizare n
programarea aplicaiilor distribuite, nc mai rmn multe sarcini de proiectare n seama celui care dezvolt
aplicaia (spre exemplu, dezvoltatorul trebuie s decid ce funcionalitate s asocieze cu clientul respectiv
serverul aplicaiei distribuite). Pentru a obine rezultate bune este necesar nelegerea problemelor aplicaiei i
valoarea pe care pot s o aib serviciile middleware pentru a ajuta aplicaia distribuit.
Pentru a determina tipurile de servicii middleware cerute de ctre situaie dezvoltatorul trebuie s identifice
funciile necesare, care pot fi ncadrate n urmtoarele clase:
Servicii pentru sisteme distribuite care includ comunicare critic, program-ctre-program i servicii de
management al datelor. Acest gen de servicii include RPC, MOM i ORB.
Servicii care fac posibile aplicaiile, care dau acces aplicaiilor la servicii distribuite i la reeaua suport.
Acest tip de servicii includ TP i servicii de baze de date (spre exemplu SQL, Structured Query
Language).
Servicii middleware de management care permit ca aplicaiile i funciile de sistem s fie monitorizate
continuu pentru a asigura performane optime ale mediului distribuit
Exist deja un numr semnificativ de servicii de tip middleware i de furnizori pentru acestea. Aplicaiile de tip
middleware vor continua s se nmuleasc odat cu creterea reelelor eterogene.
Un exemplu de aplicaie middleware este sistemul de gestionare a transportului de mrfuri pentru
compania Delta Airlines, care utilizeaz tehnologia middleware pentru a conecta
40 000 de terminale
din 32 de ri folosind servicii Unix i IBM.
Costurile legate de utilizarea tehnologiei middleware (spre exemplu, costul licenelor) n cadrul costurilor legate
de dezvoltarea unui sistem sunt dependente de sistemul de operare i de tipurile platformelor. Implementrile
middleware sunt unice i depind de furnizor. Aceasta nseamn o dependen de furnizor n ceea ce privete
suportul tehnic i ntreinerea i de asemenea pentru viitoare mbuntiri. Aceast dependen poate avea efecte
negative asupra flexibilitii sistemului i asupra mentenabilitii acestuia. Totui, atunci cnd se face evaluarea
costului dezvoltrii unei soluii middleware unice, dezvoltatorul i cel care face ntreinerea pot considera ca i
acceptabil acest efect relativ negativ.
2.5.4. Tipuri de middleware
n continuare sunt prezentate cteva tipuri de middleware, fr a acoperi ntreaga gama de aplicaii care este
extrem de larg.
Middleware orientat pe mesaje (Message Oriented Middleware) o categorie larg care include stocare
asincron i posibiliti de retransmitere a mesajelor ntre aplicaii i de asemenea include brokeri de integrare
care realizeaz transformri de mesaje i rutri sau coordonare de procese de business.
Middleware Obiect (Object Middleware) categorie format din brokeri asociai cu cereri de obiecte (Object
Request Borkers).
RPC Middleware (Remote Procedure Call Middleware ) categorie care susine procedurile de apel pe
sisteme la distan. Spre deosebire de MOM, RPC reprezint interaciunile sincrone dintre sisteme i este uzual
folosit n cadrul unei aplicaii.
Database Middleware permite accesul direct la structuri de date i asigur interaciunea direct cu bazele de
date. Exist gateways pentru baze de date i o varietate de opiuni de conectare. Pachetele ETL (Extract,
Transform, Load) sunt incluse n aceast categorie.
Middleware de tip tranzacie categorie care include monitorizri de procese de tranzacie tradiionale (TPM,
Transaction Processing Monitors) i servere de aplicaii Web.
Portaluri exist surse n literatur care includ i acest gen de aplicaii n middleware (enterprise portal servers)
deoarece acestea fcailiteaz integrare de tip front end, permind interaciunea ntre desktop-ul utilizatorului
i sistemele i serviciile back end.

2.6. Arhitectura orientat pe servicii

Aceast concept (Service Oriented Architecture SOA) este o abordare bazat pe standarde, pentru a permite
gestionarea serviciilor fcute disponibile de diverse pachete software, care s permit astfel refolosire i
reconfigurare uoar.
Acest concept, promovat de mai multe companii (inclusiv IBM i Microsoft) permite utilizarea n aplicaii a
software-ului elaborat de mai multe companii, asigurndu-se astfel interoperabilitatea. Standardele SOA includ
protocoale de comunicaie cu serviciile, descrieri de date, definirile mecanismelor utilizate, regulile de utilizare
etc.
Serviciile sunt scrise pe baza unor protocoale comune de comunicaie, interschimbabile, pentru a ocoli astfel
problemele ridicate de interfeele specifice aplicaiilor, care variaz i de la platform la platform, sau odat cu
limbajul de programare sau sistemul de operare.
Serviciile asigur un mecanism de rspuns la ntrebrile pe care o aplicaie le adreseaz alteia, pentru a cere
informaii.
Exemple din ngrijirea sntii: Aflarea adresei pacientului, D-mi rezultatele analizelor de
laborator ale acestui pacient sau Caut costul acestei reete
Multe organizaii definesc soluiile lor bazate pe servicii n termeni de servicii i conexiuni. Astfel, un serviciu
este n general implementat ca o entitate software grosier (course-grained), accesibil, care exist ntr-o
singur instan i interacioneaz cu aplicaiile sau alte servicii prin intermediul unui cuplaj slab, bazat pe un
model de comunicare prin mesaje:

Un serviciu este o funciune bine definit, auto-suficient i nu depinde de context, stare sau alte servicii.
Serviciile sunt ceea ce serviciile Web (Web Services) conecteaz mpreun. Un serviciu este captul unei
conexiuni. Abordarea SOA reprezint o evoluie n cadrul abordrilor de procesare distribuit care se distinge
prin aceea c face o separare strict a responsabilitilor i intereselor (concerns) prin utilizarea unor interfee
externe standard. n timp ce principiile nu sunt legate de o tehnologie anume, SOA este de regul implementat
prin Servicii Web deoarece acest cadru tehnologic ofer condiii pentru aplicarea celor mai importante principii
(separarea responsabilitilor i intereselor si definirea standardelor de interfa) ale SOA.
Cei 7 pai de utilizare n practic a conceptelor asociate SOA sunt:
1. Crearea/Expunerea Serviciilor
2. nregistrarea Serviciilor
3. Securizarea Serviciilor
4. Gestiunea (monitorizarea) Serviciilor
5. Medierea i Virtualizarea Serviciilor
6. Administrarea SOA
7. Integrarea Servicilor
SOA exprim o perspectiv asupra arhitecturii software care definete utilizarea seviciilor care corespund
cerinelor utilizatorilor. ntr-un mediu SOA, resursele din reea sunt fcute disponibile ca servicii independente
care pot fi accesate fr ca utilizatorul s cunoasc detalii despre implementarea specific platformei. Uzual,
SOA se bazeaz pe standarde de acces specifice Serviciilor WEB (SOAP Simple Object Access Protocol,
REST) care sunt folosite pe scar larg de industria software. Interfeele Serviciilor WEB sunt descrise n
termeni de WSDL (Web Services Description Language) pentru a putea fi nregistrate n directori publici i
cutate n depozite UDDI (Universal Description, Discovery and Integration repositories). Suportul pentru
transportul informaiei este formatul XML (Extensible Markup Language).

Tehnologii posibile pentru implementare sunt:

SOAP (Simple Object Access Protocol utilizat de serviciile WEB n Microsoft.NET), RPC (Remote
Procedure Call)

REST

DCOM

CORBA

Web services

DDS

Java RMI

WCF (implementarea Microsoft's a serviciilor WEB, acum parte a WCF Windows Communication
Services)

Apache Thrift

SORCER

Manifesto SOA:
The manifesto provides a broad definition of SOA, the values it represents for the signatories and some guiding
principles. The manifesto prioritizes:

Business value over technical strategy

Strategic goals over project-specific benefits

Intrinsic interoperability over custom integration

Shared services over specific-purpose implementations

Flexibility over optimization

Evolutionary refinement over pursuit of initial perfection