Tehnici Avansate de Ingineria Programrii Cursul 13 11

  • Slides: 30
Download presentation
Tehnici Avansate de Ingineria Programării Cursul 13 – 11 Ianuarie 1

Tehnici Avansate de Ingineria Programării Cursul 13 – 11 Ianuarie 1

Cuprins � Despre � TAIP: examen ◦ Design orientat obiect: SOA, principii de design

Cuprins � Despre � TAIP: examen ◦ Design orientat obiect: SOA, principii de design orientat obiect ◦ Dezvoltarea şi mentenanţa sistemelor: MDD, dezvoltare agilă condusă de model, design condus de domeniu, dezvoltare condusă de teste, refactorizare ◦ Modelare, modelarea afacerilor: BPMN, DSL, cadre de lucru: Eclipse Modeling Framework, OAW 2

Examen scris � Tematici: IP, TAIP, logică, cunoştinţe generale, etc. � 120 de puncte

Examen scris � Tematici: IP, TAIP, logică, cunoştinţe generale, etc. � 120 de puncte 30 de minute � Răspunsurile scurte la obiect (spațiul alocat răspunsului sugerează mărimea răspunsului așteptat) � Data: 18 Ianuarie ◦ Între 8 -9 numele care încep cu A-H ◦ Între 9 -10 numele care încep cu I-Z 3

Conţinut IP (Ce știți…) Ingineria programării (Software engineering) Modele de proiectare (Design models) Ingineria

Conţinut IP (Ce știți…) Ingineria programării (Software engineering) Modele de proiectare (Design models) Ingineria cerinţelor (Requirements identification) Diagrame UML (UML diagrams) Design patterns Testare şi debug (Testing and debugging) Întreţinere (Maintenance) Metrici software (Software metrics) Drepturi de autor (Author rights) 4

Conținut TAIP (Ce ar fi trebuit să facem…) Design orientat obiect clase: recapitulare GRASP

Conținut TAIP (Ce ar fi trebuit să facem…) Design orientat obiect clase: recapitulare GRASP și nivel mediu: GOF, nivel ridicat: stiluri arhitecturale (şabloane), SOA, principii de design orientat obiect Dezvoltarea şi mentenanţa sistemelor: dezvoltare agilă condusă de model, design condus de domeniu, dezvoltare condusă de teste, refactorizare Modelare, modelarea afacerilor: BPMN, limbaje specifice domeniu (DSL), cadre de lucru: Eclipse Modeling Framework, Open Architecture Ware (OAW) 5

SOA � SOA (Service Oriented Architecture) presupune distribuirea funcţionalităţii aplicaţiei în unităţi mai mici,

SOA � SOA (Service Oriented Architecture) presupune distribuirea funcţionalităţii aplicaţiei în unităţi mai mici, distincte - numite servicii - care pot fi distribuite într-o reţea şi pot fi utilizate împreună pentru a crea aplicaţii complexe � Serviciile sunt unităţi funcţionale independente, ce rezolvă probleme punctuale și pot fi combinate pentru a rezolva probleme complexe. � De asemenea pot fi reutilizate în aplicaţii diferite 6

SOA - Exemple � Exemple de servicii: ◦ completarea unei cereri online pentru crearea

SOA - Exemple � Exemple de servicii: ◦ completarea unei cereri online pentru crearea unui cont ◦ vizualizarea unui extras de cont ◦ efectuarea unei comenzi de bilet de avion online ◦ Pentru un robot: servicii pentru văz, auzit, deplasat 7

SOA –. Net. ROBOT – Tudor D. 8

SOA –. Net. ROBOT – Tudor D. 8

Implementing SOA the right way 9

Implementing SOA the right way 9

10

10

Principii de design OO � Arhitectură și dependințe: Când spunem că avem un proiect

Principii de design OO � Arhitectură și dependințe: Când spunem că avem un proiect degradat? � Principii de proiectare a claselor: � Principii de proiectare a arhitecturii: responsabilitate, dependențe, separare ◦ Reutilizare, versionare, închidere ◦ Cuplare, dependențe � Șabloane de proiectare OO: ◦ Abstract server, Adapter, Observer, Bridge, Abstract Factory 11

Arhitectură degradată � Rigidă – greu de modificat � Fragilă – modificările au efecte

Arhitectură degradată � Rigidă – greu de modificat � Fragilă – modificările au efecte nedorite � Imobilă – separarea în componente e dificilă � Vâscoasă – lucrurile nu curg cum trebuie � Cumplexitate suplimentară � Repetiție suplimentară � Opacitate – greu de înțeles 12

Proiectarea claselor - Principii � Responsabilitate unică (coeziune) � Deschis-închis (eliminarea modificărilor în cascadă)

Proiectarea claselor - Principii � Responsabilitate unică (coeziune) � Deschis-închis (eliminarea modificărilor în cascadă) � Substituției (Liskov) - Subclasele se pot pune oriunde apar clasele lor de bază � Principiul inversării dependențelor (Hollywood) � Separarea interfețelor - Programele client nu trebuie forţate să depindă de metodele pe care nu le folosesc 13

Dezvoltarea şi mentenanţa sistemelor � Dezvoltarea condusă de model � Dezvoltare agilă condusă de

Dezvoltarea şi mentenanţa sistemelor � Dezvoltarea condusă de model � Dezvoltare agilă condusă de model � Dezvoltarea condusă de domeniu � Dezvoltare condusă de teste � Refactorizare 14

Dezvoltarea condusă de model � Model-driven development (MDD) - metodologie software orientată pe crearea

Dezvoltarea condusă de model � Model-driven development (MDD) - metodologie software orientată pe crearea de modele apropiate de un domeniu specific decât de concepte informatice � Scopul MDD: mărirea productivității prin mărirea compatibilității dintre sisteme � Cum? Simplificând procesele de design, și promovând comunicarea atât între oamenii din echipă, cât și între echipele care lucrează la acel proiect. � În MDD se consideră utile modelele care pot fi înțelese de utilizator, urmând ca pe baza acestora să se construiască sistemul final 15

Model-driven architecture � MDA este cea mai cunoscută inițiativă din MDD și a fost

Model-driven architecture � MDA este cea mai cunoscută inițiativă din MDD și a fost lansată de grupul OMG (Object Management Group) în 2001 � MDA are la bază un set de reguli pentru realizarea specificațiilor, care sunt date prin intermediul modelelor � În MDA, OMG s-a concentrat pe forward engineering � Scopul de bază ale MDA: separarea dintre design și arhitectura sistemului => Grupurile pot să dezvolte separat, obținând ceea ce e mai bun în ambele direcții 16

Dezvoltare agilă condusă de model � AMDD este versiunea agilă a MDD 17

Dezvoltare agilă condusă de model � AMDD este versiunea agilă a MDD 17

Dezvoltare condusă de teste � Test-Driven Development – TDD Pașii TDD: 1. Adăuga un

Dezvoltare condusă de teste � Test-Driven Development – TDD Pașii TDD: 1. Adăuga un test. 2. Executa testele; testul nou eșuează. 3. Actualizează codul funcțional a. i. să treacă toate testele. 4. Execută testele din nou. ◦ ◦ 5. Dacă testele eșuează, treci la 3. Dacă testele trec cu succes, putem continua cu altă funcționalitate Restructurează codul funcțional și de testare 18

Tipuri de teste �Unit testing �Integration testing �Functional testing �Acceptance testing �Performance testing 19

Tipuri de teste �Unit testing �Integration testing �Functional testing �Acceptance testing �Performance testing 19

Refactorizare (Refactoring) � Schimbările succesive conduc la o structură suboptimă a codului ◦ Crește

Refactorizare (Refactoring) � Schimbările succesive conduc la o structură suboptimă a codului ◦ Crește complexitatea ◦ Scade claritatea � Refactorizarea este o schimbare în structura internă a unui produs software cu scopul de a-l face mai ușor de înțeles și de modificat fără a-i schimba comportamentul observabil � Rezultate: ◦ Scăderea cuplării ◦ Creșterea coeziunii 20

Refactorizare - Detalii � Schimbările pot introduce noi defecte ◦ Refactorizarea trebuie efectuatã în

Refactorizare - Detalii � Schimbările pot introduce noi defecte ◦ Refactorizarea trebuie efectuatã în pași mici ◦ Trebuie să existe teste care să indice locurile unde apar erori � Refactorizarea funcționalități nu se referă la introducerea de noi ◦ Cele două activități trebuie despărțite � Refactorizarea îmbunătățește structura, nu codul ◦ Codul prost scris nu trebuie refactorizat, ci rescris � Refactorizarea nu trebuie să introducă niveluri de complexitate inutile � Costurile suplimentare ale refactorizării sunt compensate de economiile ulterioare 21

Refactorizare - Când? � Următoarele situații sunt semnale pentru necesitatea refactorizării: Cod duplicat Metode

Refactorizare - Când? � Următoarele situații sunt semnale pentru necesitatea refactorizării: Cod duplicat Metode lungi Clase mari Liste lungi de parametri Instrucțiuni switch după tipul obiectelor - Se recomandã polimorfismul ◦ Generalitate speculativă - Ierarhie de clase în care subclasele au acelașii comportament ◦ Comunicare intensă între obiecte (cuplare puternicã) ◦ Înlănțuirea de mesaje ◦ ◦ ◦ 22

Refactorizare – Cum? 23

Refactorizare – Cum? 23

Modelare, modelarea afacerilor � BPMN � Limbaje specifice domeniu (DSL) � Cadre de lucru:

Modelare, modelarea afacerilor � BPMN � Limbaje specifice domeniu (DSL) � Cadre de lucru: ◦ Eclipse Modeling Framework ◦ Open Architecture Ware (OAW) 24

BPMN � Business Process Modelling Notation (BPMN) is a graphical representation for specifying business

BPMN � Business Process Modelling Notation (BPMN) is a graphical representation for specifying business processes in a workflow 25

BPMN - Example 26

BPMN - Example 26

Eclipse Modeling Framework � EMF is an Eclipse-based modeling framework and code generation facility

Eclipse Modeling Framework � EMF is an Eclipse-based modeling framework and code generation facility for building tools and other applications based on a structured data model 27

Links � � � SOA: http: //www-01. ibm. com/software/solutions/soa/ , http: //ro. wikipedia. org/wiki/SOA

Links � � � SOA: http: //www-01. ibm. com/software/solutions/soa/ , http: //ro. wikipedia. org/wiki/SOA for the real world: http: //www. javaworld. com/javaworld/jw 11 -2006/jw-1129 -soa. html? page=1 Abstract Server http: //today. java. net/pub/a/today/2004/06/8/patterns. html Agile Model Driven Development (AMDD) http: //www. agilemodeling. com/essays/amdd. htm Florin Leon – IP Curs 11 http: //eureka. cs. tuiasi. ro/~fleon/Curs_IP/IP 11_Implementarea. pdf OAW http: //www. openarchitectureware. org/ 28

Bibliografie Cecil Martin: Design Principles and Design Patterns. www. objectmentor. com. � Robert Cecil

Bibliografie Cecil Martin: Design Principles and Design Patterns. www. objectmentor. com. � Robert Cecil Martin: Agile Development. Principles, Patterns, and Practices, Prentice-Hall, 2003 � Robert 29

Vă Mulţumesc! Pentru prezenţă, răbdare, colaborare. . . 30

Vă Mulţumesc! Pentru prezenţă, răbdare, colaborare. . . 30