Managementul Proiectelor Software

Laborator 8 - Integrare

Ce înseamnă "integrare"? (5 min)

Cu puține excepții, proiectele software nu sunt izolate și auto-suficiente, ci depind de alte sisteme, fiind părți dintr-un întreg mai mare. Userii se așteaptă să poată folosi transparent toate funcțiile acestui întreg, indiferent de componenta software din care o anumită funcție face parte. Pentru aceasta, diferitele componente trebuie conectate într-o soluție mai largă. Acest proces este integrarea. De obicei, ea constă în “cablarea” datelor și informației între componente.

Această “cablare” presupune de obicei:

  • definirea datelor de care diferitele componente au nevoie
  • definirea flow-ului acestor date (sursă, storage comun, destinație)
  • definirea interfețelor prin care componentele comunică între ele
  • definirea hardware-ului pe care o componentă software va fi instalată (“deployed”)
  • în cazul în care componenta în cauză are ea însăși subcomponente conectate, pașii de mai sus trebuie repetați pentru subcomponente (ex. un același proiect software poate avea nevoie de mai multe tipuri de hardware: serverul fizic de baze de date, servere, middle tier - fiecare având instalate doar anumite module și nu tot proiectul)

Integrarea: un task dificil?

De obicei, DA. Motivele sunt mai multe:

Cerințe divergente

Cerințele integrării sunt de multe ori în contradicție cu cerințele de arhitectură ale proiectului. Ex. din motive de performanță, o componentă software ar putea avea nevoie de un storage local mai curând decât de date remote. Integrarea acestei componente într-un sistem mai larg ar putea însă presupune accesul remote la acele date, și anume printr-o interfață.

Evoluția sistemului

Un sistem evoluează în timp: se adaugă noi features, noi componente, noi date. De multe ori, sistemul nu mai este optimal pentru cerințele noii componente - sau reciproc, componentele mai vechi se dovedesc depășite de noile cerințe.

Complexitatea

Un sistem are adeseori o complexitate imposibil de stăpânit de către un singur om. Integrarea poate fi deci un proiect în sine, cerând conlucrarea unei întregi echipe.

Impactul

Integrarea unei componente noi poate afecta funcționarea celorlalte - fie by design, fie în urma unor buguri. De exemplu, fie o componentă nouă X care accesează o componentă preexistentă, Y. Componenta X poate transfera niște date eronate, care pot provoca inconsistențe la nivelul storage-ului din Y, sau pot scoate la iveală buguri preexistente (și anterior necunoscute) în componenta X.

Securitatea

De asemenea, mai ales în mediul de Web, sunt întotdeauna posibile security breaches. În funcție de modul de cuplare al componentelor, aceste security breaches pot fi mai mult sau mai puțin periculoase. De exemplu, accesul direct al unei componente server side la o bază de date înseamnă că un security breach pe server se poate solda cu acces la baza de date.

Abordări și best practices

Integrarea stea

Integrarea “stea” (sau “spaghetti”) presupune interconectarea fiecărei componente cu toate celelalte, refolosind la maximum funcționalitățile existente.

Avantajul este economia: refolosirea la maximum a funcționalităților existente în fiecare sistem duce la simplificarea componentelor, care trebuie să implementeze doar interfețe și nu să duplice funcționalități.

Dezavantajul rezidă însă la nivelul evoluției sistemului: pe masură ce crește numărul de componente, crește și numărul de conexiuni: fiecare componentă va avea O(N) conexiuni, deci numărul total va fi:

Treptat, un asemenea sistem ajunge să “scape de sub control”. Adăugarea de noi features - care era foarte simplă în stadiile inițiale - devine ineficientă din cauza overheadului de conectare.

Integrarea verticală

Integrarea verticală presupune crearea de componente cvasi-autonome. În acest scop, fiecare componentă va duplica părți din funcționalitatea celorlalte, inclusiv storage.

Avantajul este că, odată ce componentele au fost concepute și implementate în acest fel, ele pot fi integrate în sistem cu costuri și impact minim. Dezavantajul este costul mai ridicat al componentelor, care nu refolosesc funcționalități și module, ci mai curând le duplică.

Integrarea orizontală

Integrarea orizontală - sau Enterprise Application Integration (EAI) - presupune crearea unei componente specializate (middleware) care este dedicată comunicației între celelalte componente. Această soluție permite reducerea numărului de conexiuni (= interfețe) la una singură pentru fiecare subsistem, urmând ca subsistemul middleware să asigure translatarea unei interfețe în alta (respectiv să “ruteze” datele de la o componentă la alta).

Avantajele sunt multiple: pe de o parte componentele au nevoie de o singură interfață, pe de altă parte ele pot refolosi funcționalitățile celorlalte. Componentele rămân separate, putând fi înlocuite sau dezvoltate fără afectarea celorlalte.

Patternuri de integrare orizontală

Din punct de vedere funcțional, într-o integrare de tip orizontal apar doua patternuri tipice, de obicei complementare:

  • Intermediere: intermedierea conectivității componentelor. Ori de câte ori are loc un eveniment (sau o cerere) într-una din componente, aceasta este distribuită corespunzător către celelalte componente prin interfețele acestora.
  • “Federation”: legarea sistemului cu mediul exterior prin intermediul interfețelor publice și ascunzând interfețele private.

Din punct de vedere al propagării evenimentelor sau cererilor, apar de asemenea două situații tipice: propagare sincronă sau asincronă. Cu exemplul din exercițiul anterior, dacă o cerere de tip self-service a unui client este condiționată de plata la timp a facturilor sale, este nevoie ca evenimentul cererii să fie propagat în timp real componentei de billing, iar răspunsul preluat în timp real: acces sincron. Dacă aceeași cerere trebuie însă să aștepte confirmarea unui operator uman, atunci nu mai este necesară așteptarea răspunsului celorlalte componente: acces asincron.

Generic, cererile de comunicație între componente se numesc “mesaje”.

Platforme pentru integrare (5 min)

Există multe soluții software care încearcă să automatizeze integrarea diverselor componente software. Cele mai cunoscute sunt următoarele două:

Application servers

Un application server este un framework care integrează componentele în jurul unui web server. Componentele comunică prin intermediul serverului. Exemple:

  • Apache Geronimo (Apache)
  • JBoss (RedHat)
  • WebSphere Application Server (IBM)
  • WebLogic Server (Oracle)

Enterprise Service Bus

Un enterprise service bus este un framework având la bazâ un layer generic de comunicare între diferite componente software. Comunicarea se face prin intermediul mesajelor. Exemple:

  • WebSphere Enterprise Service Bus (IBM)
  • Enterprise Service Bus (Oracle)
  • Progress Sonic ESB

Integration testing (5 min)

“Integration testing” reprezintă testarea funcționalității, performanței și stabilității sistemelor compuse. Este un “black box testing”, în sensul că testarea nu se face la nivelul componentelor sistemului, ci la nivelul interfețelor acestora. Cazurile de succes și eroare sunt testate prin inputuri (parametri și date) simulate corespunzător.

Scenariile de testare (“test cases”) urmăresc să verifice felul în care componentele interacționeaza una cu alta. Această etapă de testare este ulterioară testării individuale a componentelor (i.e. unit testing) și presupune că toate componentele sunt deja funcționale și corespund specificațiilor.

Exista trei abordări principiale pentru testarea integrării:

Botom-up

Testarea bottom-up presupune testarea componentelor de la nivelul cel mai jos, urcând progresiv către componentele de nivel înalt până către ansamblul sistemului. La nivelul cel mai de jos, se integrează procedurile sau funcțiile în modulele respective, apoi sunt testate. După aceea, se integrează modulele și se face o nouă rundă de testare. Acest tip de testare este foarte eficace în găsirea bugurilor, și de asemenea ușor de monitorizat (se poate ști în fiecare moment ce procent din teste a fost terminat). Are însa marele dezavantaj că nu testează logica și flow-urile principale de date până foarte târziu în cadrul proiectului, ceea ce face ca eventualele greșeli de design să fie depistate relativ târziu. De asemenea, nu permite un eventual release parțial, cu funcționalități limitate.

Top-down

Testarea top-down presupune integrarea și testarea modulelor începând cu cele de la nivelul cel mai inalt. Avantajul este că logica și flowurile principale de date sunt testate mai devreme, deci orice greșeala de design este depistată în timp util. Dezavantajul constă însă în overheadul mare necesar pentru test cases și pentru simulările de date, în condițiile în care sistemele nu sunt terminate și funcționale. Alt dezavantaj este că modulele de nivel jos sunt testate relativ târziu în cadrul proiectului. Nici acest model nu permite un release parțial, cu funcționalități limitate.

"Umbrella" sau "Sandwich"

Este o combinație a celor două metode de mai sus. În prima fază, se testează funcțiile de nivel jos, ca în cazul abordării bottom-up. Ieșirile funcțiilor sunt apoi integrate și testate în maniera top-down. Este o metodă mai puțin sistematică decât oricare dintre cele două anterioare, și mai puțin exactă, însă avantajul este că permite release-uri parțiale, cu funcționalități limitate, înainte de terminarea întregului proiect.

Service Oriented Architecture (SOA)

SOA reprezintă un set de guidelines de arhitectură pentru sisteme scalabile și extensibile. Ideea de bază este ca fiecare componentă software să își exporte funcționalitățile sub forma unui serviciu accesibil remote, ceea ce deschide calea sistemelor complexe, flexibile și refolosibile. SOA nu este propriu zis o rețetă, ci o colecție de principii:

  1. Incapsulare - componentele nu au restricții de arhitectură internă
  2. Cuplare slabă - componentele trebuie să aibă dependințe reciproce cât mai mici
  3. “Contract de servicii” - componentele aderă la o specificație comună de comunicare și conlucrare reciprocă
  4. Abstractizare - componentele nu expun public logica lor internă
  5. Refolosire - împărțirea pe servicii este gândită în vederea refolosirii
  6. Combinabilitatea - serviciile pot fi combinate și încapsulate sub forma unui serviciu
  7. Autonomie - serviciile au control total asupra logicii lor interne
  8. Optimizare - între două servicii echivalente, se va prefera serviciul mai bun din punct de vedere calitativ
  9. Descoperire - serviciile exportă informații care permit descoperirea și folosirea lor de către alte servicii
  10. Relevanță - serviciile trebuie să aibă valoare pentru end-useri

Exemplu: Flickr.com, Google.com, Facebook.com - toate sunt gândite ca SOA, exportând servicii prin intermediul unui API. Consecințe: funcționalități ca Google search sau Google maps sunt integrabile în contexte (pagini sau aplicații Desktop) în afara lui Google. În mediul web, acest gen de servicii integrabile în cvasi-orice context se numesc widgets.

Bibliografie

Exerciții

Team Management WebApp (40 de minute)

Vi se propune realizarea unei aplicații de team management: organizare echipă, task-uri, mesagerie, subechipe etc. Aplicația va fi disponibilă în forma unei interfețe web.

Se propun patru module:
i) interfața cu utilizatorul
ii) gestiunea persistenței și bazei da date
iii) core-ul (engine-ul aplicației)
iv) interfațarea cu alte servicii de tipul Facebook, Google+, LinkedIn, e-mailing

Discutați între voi și împărțiți-vă în patru echipe conform cu modulele de mai sus.

În cadrul fiecărei echipe discutați despre ideile de proiectare și implementare a modulului (ce biblioteci, limbaje, framework-uri propuneți etc.).

Fie printr-un reprezentant, fie la un loc, discutați cu celelalte echipe care să fie interfețele de comunicare între module.

După discuție, reanalizați cât de potrivite sunt acele interfețe pentru propunerile voastre de proiectare și implementare. Ce actualizări sunt necesare?

După reanaliză, prezentați propunerile voastre celorlalte echipe. Discutați despre problemele posibile de integrare ale modulelor celorlalte echipe; la nivel de feedback constructiv.

Dropbox-like App (40 de minute)

Vi se propune implementarea unei aplicații similare Dropbox, care să meargă și pe sisteme desktop și pe dispozitive mobile și să aibă și interfață web.

Împărțiți-vă în patru echipe cu următoarele responsabilități:
i) proiectarea și implemenarea aplicației client pe sistem desktop
ii) proiectarea și implementarea aplicației client pe dispozitiv mobil
iii) protocolul de comunicare între client și server
iv) proiectarea aplicației pe server și interfața web

Intern discutați despre nevoi pentru echipa voastră; precizați ce module va deține componenta de care vă ocupați. Fie prin reprezentanți fie la comun, discutați cu celelalte echipe despre modulele lor. Ce module pot fi comune? Ce interfețe puteți defini/sunt necesare între responsabilitatea proprie și cea a celorlalte echipe? Gândiți-vă să facilitați cât mai mult integrarea componentelor.

laboratoare/laborator-08.txt · Last modified: 2012/11/20 17:48 by andrei.maruseac