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

Info. comanda Nr. comanda & expeditie & proces asigurare comanda

& proces expeditie proces generare

nota plata

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