Differences
This shows you the differences between two versions of the page.
|
mps:laboratoare:laborator-08 [2016/09/28 17:08] 127.0.0.1 external edit |
mps:laboratoare:laborator-08 [2020/12/02 15:02] (current) iulia.stanica [Lucru la proiect (30 de minute)] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | = Laborator 8 - Integrare = | + | ====== Laborator 8 - Integrare ====== |
| - | == Ce înseamnă "integrare"? (5 min) == | + | ===== 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. Utilizatorii 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 impreună. **Acest proces este integrarea**. De obicei, ea constă în "cablarea" datelor și informației între componente. | 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. Utilizatorii 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 impreună. **Acest proces este integrarea**. De obicei, ea constă în "cablarea" datelor și informației între componente. | ||
| Line 7: | Line 7: | ||
| Această "cablare" presupune de obicei: | Această "cablare" presupune de obicei: | ||
| - | * definirea datelor de care diferitele componente au nevoie | + | * definirea datelor de care diferitele componente au nevoie |
| - | * definirea transferului acestor date (sursă, storage comun, destinație) | + | * definirea transferului acestor date (sursă, storage comun, destinație) |
| - | * definirea interfețelor prin care componentele să comunice între ele | + | * definirea interfețelor prin care componentele să comunice între ele |
| - | * definirea hardware-ului pe care o componentă software va fi instalată ("deployed") | + | * 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)// | + | * î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? == | + | ===== Integrarea: un task dificil? ===== |
| De obicei, **DA**. Motivele sunt mai multe: | De obicei, **DA**. Motivele sunt mai multe: | ||
| - | === Cerințe divergente === | + | ==== 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 ar putea însă presupune accesul remote la acele date, printr-o interfață.// | 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 ar putea însă presupune accesul remote la acele date, printr-o interfață.// | ||
| - | === Evoluția sistemului === | + | ==== Evoluția sistemului ==== |
| Un sistem evoluează în timp: se adaugă noi funcționalități, noi componente, noi date. De multe ori, sistemul nu mai este optimal pentru cerințele noii componente - sau componentele mai vechi se dovedesc depășite de noile cerințe. | Un sistem evoluează în timp: se adaugă noi funcționalități, noi componente, noi date. De multe ori, sistemul nu mai este optimal pentru cerințele noii componente - sau componentele mai vechi se dovedesc depășite de noile cerințe. | ||
| - | === Complexitatea === | + | ==== 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, necesitând conlucrarea unei întregi echipe. | 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, necesitând conlucrarea unei întregi echipe. | ||
| - | === Impactul === | + | ==== Impactul ==== |
| Integrarea unei componente noi poate afecta funcționarea celorlalte. //De exemplu: o componentă nouă X accesează o componentă preexistentă, Y. Componenta X poate transfera date eronate care să provoace inconsistențe la nivelul datelor din Y, sau să scoată la iveală buguri preexistente (și anterior necunoscute) din componenta Y.// | Integrarea unei componente noi poate afecta funcționarea celorlalte. //De exemplu: o componentă nouă X accesează o componentă preexistentă, Y. Componenta X poate transfera date eronate care să provoace inconsistențe la nivelul datelor din Y, sau să scoată la iveală buguri preexistente (și anterior necunoscute) din componenta Y.// | ||
| - | === Securitatea === | + | ==== Securitatea ==== |
| De asemenea, mai ales în mediul de Web, pot apărea //breșe de securitate//. În funcție de modul de cuplare al componentelor, aceste breșe de securitate pot fi mai mult sau mai puțin periculoase. //De exemplu: accesul direct a unei componente de pe server la o bază de date poate introduce o breșă în securitatea bazei de date. Compromiterea serverului atrage după sine și compromiterea datelor din baza de date.// | De asemenea, mai ales în mediul de Web, pot apărea //breșe de securitate//. În funcție de modul de cuplare al componentelor, aceste breșe de securitate pot fi mai mult sau mai puțin periculoase. //De exemplu: accesul direct a unei componente de pe server la o bază de date poate introduce o breșă în securitatea bazei de date. Compromiterea serverului atrage după sine și compromiterea datelor din baza de date.// | ||
| - | == Abordări de Integrare == | + | ===== Abordări de Integrare ===== |
| - | === Integrarea stea === | + | ==== Integrarea stea ==== |
| Integrarea "stea" (sau "spaghetti") presupune interconectarea fiecărei componente cu toate celelalte, refolosind la maximum funcționalitățile existente. | Integrarea "stea" (sau "spaghetti") presupune interconectarea fiecărei componente cu toate celelalte, refolosind la maximum funcționalitățile existente. | ||
| Line 51: | Line 51: | ||
| Treptat, un asemenea sistem ajunge să "scape de sub control". Adăugarea de noi funcționalități - care era foarte simplă în stadiile inițiale - devine ineficientă din cauza overheadului de conectare. | Treptat, un asemenea sistem ajunge să "scape de sub control". Adăugarea de noi funcționalități - care era foarte simplă în stadiile inițiale - devine ineficientă din cauza overheadului de conectare. | ||
| - | === Integrarea verticală === | + | ==== 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. | Integrarea verticală presupune crearea de componente cvasi-autonome. În acest scop, fiecare componentă va duplica părți din funcționalitatea celorlalte, inclusiv storage. | ||
| Line 57: | Line 57: | ||
| 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 constă în costul mai ridicat al componentelor, care nu refolosesc funcționalități și module, ci mai curând le duplică. | 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 constă în costul mai ridicat al componentelor, care nu refolosesc funcționalități și module, ci mai curând le duplică. | ||
| - | === Integrarea orizontală === | + | ==== Integrarea orizontală ==== |
| - | Integrarea orizontală - sau [[http://en.wikipedia.org/wiki/Enterprise_application_integration | Enterprise Application Integration]] (EAI) - presupune crearea unei componente specializate (//[[http://en.wikipedia.org/wiki/Middleware | 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). | + | Integrarea orizontală - sau [[http://en.wikipedia.org/wiki/Enterprise_application_integration | Enterprise Application Integration]] (EAI) - presupune crearea unei componente specializate (//[[http://en.wikipedia.org/wiki/Middleware | 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. | 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ă == | + | ===== Patternuri de integrare orizontală ===== |
| Din punct de vedere funcțional, într-o integrare de tip orizontal apar doua patternuri tipice, de obicei complementare: | 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. Componentele folosesc structuri proprii pentru mesajele cu care comunică; mesajele sunt transformate din forma expeditorului într-o structură specifică destinatarului. | + | * **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. Componentele folosesc structuri proprii pentru mesajele cu care comunică; mesajele sunt transformate din forma expeditorului într-o structură specifică destinatarului. |
| - | * **"Federation"**: legarea sistemului cu mediul exterior prin intermediul interfețelor publice și ascunzând interfețele private. Componentele cad de acord asupra structurii mesajelor și toate folosesc aceiași structură. | + | * **"Federation"**: legarea sistemului cu mediul exterior prin intermediul interfețelor publice și ascunzând interfețele private. Componentele cad de acord asupra structurii mesajelor și toate folosesc aceiași structură. |
| Din punct de vedere al propagării evenimentelor sau cererilor, apar de asemenea două situații tipice de transmitere a mesajelor: | Din punct de vedere al propagării evenimentelor sau cererilor, apar de asemenea două situații tipice de transmitere a mesajelor: | ||
| - | * **Sincronă**: Este acea comunicare în care toate părțile participă în același timp la curgerea mesajelor. Aceasta necesită transmiterea mesajului de un participant X, blocarea lui până la primirea răspunsului, prelucrarea mesajului de un participant Y, trimiterea răspunsului înapoi la X. Un exemplu este convorbirea la telefon, în care e necesar ca cel cu care vreau să vorbesc să fie lângă telefon în momentul în care sun. Avantajul acestui tip de comunicare îl reprezintă simplitatea, dar apar dezavantaje precum pierderea timpului, blocarea unui thread în asteptarea răspunsurilor, suprasolicitarea unui destinatar comun. | + | * **Sincronă**: Este acea comunicare în care toate părțile participă în același timp la curgerea mesajelor. Aceasta necesită transmiterea mesajului de un participant X, blocarea lui până la primirea răspunsului, prelucrarea mesajului de un participant Y, trimiterea răspunsului înapoi la X. Un exemplu este convorbirea la telefon, în care e necesar ca cel cu care vreau să vorbesc să fie lângă telefon în momentul în care sun. Avantajul acestui tip de comunicare îl reprezintă simplitatea, dar apar dezavantaje precum pierderea timpului, blocarea unui thread în asteptarea răspunsurilor, suprasolicitarea unui destinatar comun. |
| - | * **Asincronă**: În această abordare transmițătorul X doar trebuie să aibă grijă că mesajul ajunge în canalul de transmisie; canalul având grijă ca mesajul să ajungă cu bine. Destinatarul, sau receptorul are o coadă în care primește mesajele și le prelucrează la viteza maximă de care dispune. În acest timp expeditorul face alte activități, nefiind blocat în așteptarea unui răspuns. Exemplu ar fi lăsarea unui mesaj în căsuța vocală a celui cu care dorim să comunicăm. Avantajele sunt evidente: separarea funcților, randament maxim, evitarea suprasolicitării; dar toată arhitectura trebuie gândită într-un mod mai complex bazat pe evenimente. | + | * **Asincronă**: În această abordare transmițătorul X doar trebuie să aibă grijă că mesajul ajunge în canalul de transmisie; canalul având grijă ca mesajul să ajungă cu bine. Destinatarul, sau receptorul are o coadă în care primește mesajele și le prelucrează la viteza maximă de care dispune. În acest timp expeditorul face alte activități, nefiind blocat în așteptarea unui răspuns. Exemplu ar fi lăsarea unui mesaj în căsuța vocală a celui cu care dorim să comunicăm. Avantajele sunt evidente: separarea funcților, randament maxim, evitarea suprasolicitării; dar toată arhitectura trebuie gândită într-un mod mai complex bazat pe evenimente. |
| Din punct de vedere al tipurilor de date transmise, acestea pot fi transferate ca și: | Din punct de vedere al tipurilor de date transmise, acestea pot fi transferate ca și: | ||
| - | * **Fișiere**: O aplicație scrie un fișier pe care o alta îl citește mai târziu. Aplicațiile trebuie să cadă de acord asupra numelui de fișier și locației, formatului de fișier, momentului când acesta va fi scris și citit, și cine va șterge fișierul. | + | * **Fișiere**: O aplicație scrie un fișier pe care o alta îl citește mai târziu. Aplicațiile trebuie să cadă de acord asupra numelui de fișier și locației, formatului de fișier, momentului când acesta va fi scris și citit, și cine va șterge fișierul. |
| - | * **Bază de date comună**: Aplicații multiple împărtășesc aceeași schemă de baze de date, situată într-o singură bază de date fizică. Deoarece nu există duplicate ale bazei de date, datele nu trebuie să fie transferate la o aplicație la alta. | + | * **Bază de date comună**: Aplicații multiple împărtășesc aceeași schemă de baze de date, situată într-o singură bază de date fizică. Deoarece nu există duplicate ale bazei de date, datele nu trebuie să fie transferate la o aplicație la alta. |
| - | * **Apelare de proceduri la distanță**: O aplicație expune anumite funcționalități astfel încât acestea să poată fi accesate de la distanță de alte aplicații, ca și proceduri la distanță. Comunicarea are loc în timp real și sincron. | + | * **Apelare de proceduri la distanță**: O aplicație expune anumite funcționalități astfel încât acestea să poată fi accesate de la distanță de alte aplicații, ca și proceduri la distanță. Comunicarea are loc în timp real și sincron. |
| - | * **Mesaje**: Aplicatiile trimit mesaje printr-un canal de mesaje comun. Alte aplicații pot citi mesajele de pe canal la un moment ulterior. Aplicațiile trebuie să cadă de acord asupra unui canal, precum și formatului mesajelor. Comunicarea este asincronă. | + | * **Mesaje**: Aplicatiile trimit mesaje printr-un canal de mesaje comun. Alte aplicații pot citi mesajele de pe canal la un moment ulterior. Aplicațiile trebuie să cadă de acord asupra unui canal, precum și formatului mesajelor. Comunicarea este asincronă. |
| - | + | ===== Service Oriented Architecture (SOA) ===== | |
| - | == Service Oriented Architecture (SOA) == | + | |
| [[http://en.wikipedia.org/wiki/Service-oriented_architecture| 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: | [[http://en.wikipedia.org/wiki/Service-oriented_architecture| 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: | ||
| - | # **Incapsulare** - componentele nu au restricții de arhitectură internă | + | - **Incapsulare** - componentele nu au restricții de arhitectură internă |
| - | # **Cuplare slabă** - componentele trebuie să aibă dependințe reciproce cât mai mici | + | - **Cuplare slabă** - componentele trebuie să aibă dependințe reciproce cât mai mici |
| - | # **"Contract de servicii"** - componentele aderă la o specificație comună de comunicare și conlucrare reciprocă | + | - **"Contract de servicii"** - componentele aderă la o specificație comună de comunicare și conlucrare reciprocă |
| - | # **Abstractizare** - componentele nu expun public logica lor internă | + | - **Abstractizare** - componentele nu expun public logica lor internă |
| - | # **Refolosire** - împărțirea pe servicii este gândită în vederea refolosirii | + | - **Refolosire** - împărțirea pe servicii este gândită în vederea refolosirii |
| - | # **Combinabilitatea** - serviciile pot fi combinate și încapsulate sub forma unui serviciu | + | - **Combinabilitatea** - serviciile pot fi combinate și încapsulate sub forma unui serviciu |
| - | # **Autonomie** - serviciile au control total asupra logicii lor interne | + | - **Autonomie** - serviciile au control total asupra logicii lor interne |
| - | # **Optimizare** - între două servicii echivalente, se va prefera serviciul mai bun din punct de vedere calitativ | + | - **Optimizare** - între două servicii echivalente, se va prefera serviciul mai bun din punct de vedere calitativ |
| - | # **Descoperire** - serviciile exportă informații care permit descoperirea și folosirea lor de către alte servicii | + | - **Descoperire** - serviciile exportă informații care permit descoperirea și folosirea lor de către alte servicii |
| - | # ** Relevanță** - serviciile trebuie să aibă valoare pentru end-useri | + | - ** 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 [[http://www.widgipedia.com|widgets]]. // | //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 [[http://www.widgipedia.com|widgets]]. // | ||
| - | {{ :laboratoare:esb-soa2.jpg |http://www.binaryspectrum.com/service-oriented_architecture/esb.html}} | ||
| - | == Platforme pentru integrare (5 min) == | + | ===== Platforme pentru integrare (5 min) ===== |
| Există multe [[http://en.wikipedia.org/wiki/Comparison_of_business_integration_software | soluții software]] care încearcă să automatizeze integrarea diverselor componente software. Cele mai cunoscute sunt următoarele două: | Există multe [[http://en.wikipedia.org/wiki/Comparison_of_business_integration_software | soluții software]] care încearcă să automatizeze integrarea diverselor componente software. Cele mai cunoscute sunt următoarele două: | ||
| - | === Application servers === | + | ==== Application servers ==== |
| Un [[http://en.wikipedia.org/wiki/Application_server | application server]] este un framework care integrează componentele în jurul unui web server. Componentele comunică prin intermediul serverului. Exemple: | Un [[http://en.wikipedia.org/wiki/Application_server | application server]] este un framework care integrează componentele în jurul unui web server. Componentele comunică prin intermediul serverului. Exemple: | ||
| - | * Apache Geronimo (Apache) | + | * Apache Geronimo (Apache) |
| - | * JBoss (RedHat) | + | * JBoss (RedHat) |
| - | * WebSphere Application Server (IBM) | + | * WebSphere Application Server (IBM) |
| - | * WebLogic Server (Oracle) | + | * WebLogic Server (Oracle) |
| - | === Enterprise Service Bus === | + | ==== Enterprise Service Bus ==== |
| Un [[http://en.wikipedia.org/wiki/Enterprise_Service_Bus | 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: | Un [[http://en.wikipedia.org/wiki/Enterprise_Service_Bus | 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) | + | * WebSphere Enterprise Service Bus (IBM) |
| - | * Enterprise Service Bus (Oracle) | + | * Enterprise Service Bus (Oracle) |
| - | * Progress Sonic ESB | + | * Progress Sonic ESB |
| - | == Integration testing (5 min) == | + | ===== Integration testing (5 min) ===== |
| [[http://en.wikipedia.org/wiki/Integration_testing | Testarea integrării componentelor]] se face pentru verificarea funcționalității, performanței și stabilității sistemelor compuse. Este un sistem tip cutie neagră, î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. | [[http://en.wikipedia.org/wiki/Integration_testing | Testarea integrării componentelor]] se face pentru verificarea funcționalității, performanței și stabilității sistemelor compuse. Este un sistem tip cutie neagră, î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. | ||
| Line 128: | Line 126: | ||
| Exista trei [[http://msdn.microsoft.com/en-us/library/aa292128 | abordări]] principiale pentru testarea integrării: | Exista trei [[http://msdn.microsoft.com/en-us/library/aa292128 | abordări]] principiale pentru testarea integrării: | ||
| - | === Botom-up === | + | ==== 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. | 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 === | + | ==== 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. | 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" === | + | ==== "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. | 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. | ||
| - | == Exerciții == | + | ===== 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: | + | |
| - | - interfața cu utilizatorul | + | |
| - | - gestiunea persistenței și bazei de date | + | |
| - | - core-ul (engine-ul aplicației) | + | |
| - | - 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. | + | ==== Story telling (30 de minute) ==== |
| - | 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? | + | Formați echipe de 2-3 persoane. O echipă pornește cu o poveste formată din 3-4 fraze. Celelalte echipe vor construi **simultan** a 2-a, a 3-a, a 4-a parte a poveștii. Vedeți la sfârșit ce a ieșit. |
| - | După reanaliză, prezentați propunerile voastre celorlalte echipe. Discutați despre problemele posibile de integrare ale modulelor celorlalte echipe; la nivel de feedback constructiv. | + | ==== Exercitiu integrare (40 de minute) ==== |
| - | === Dropbox-like App (40 de minute) === | + | * Identificati componentele proiectului. Ce abordare de integrare considerati ca este potrivita pentru proiectul vostru? Justificati alegerea. |
| + | * Alegeti abordarea de integration testing potrivita pentru proiectul vostru. Justificati alegerea. | ||
| + | * Prezentati alegerile facute in fata colegilor. Aduceti argumente pro pentru alegerile voastre / contra alegerilor colegilor. | ||
| - | Vi se propune implementarea unei aplicații similare [[https://www.dropbox.com/|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: | + | <hidden>==== Lucru la proiect (30 de minute) ==== |
| - | - proiectarea și implemenarea aplicației client pe sistem desktop | + | Continuati lucrul la proiect.</hidden> |
| - | - proiectarea și implementarea aplicației client pe dispozitiv mobil | + | |
| - | - protocolul de comunicare între client și server | + | |
| - | - 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. | + | ===== Bibliografie ===== |
| - | == Bibliografie == | + | * http://www.enterpriseintegrationpatterns.com/Introduction.html |
| + | * http://msdn.microsoft.com/en-us/library/ms978729.aspx | ||
| - | * http://www.enterpriseintegrationpatterns.com/Introduction.html | ||
| - | * http://msdn.microsoft.com/en-us/library/ms978729.aspx | ||
