Cursul 13 – 11 Ianuarie Despre examen TAIP: ◦ Design orientat obiect: SOA, principii de design orientat obiect ◦ Dezvoltarea şi mentenanţa sistemelor: MDD, dezvoltare.
Download ReportTranscript Cursul 13 – 11 Ianuarie Despre examen TAIP: ◦ Design orientat obiect: SOA, principii de design orientat obiect ◦ Dezvoltarea şi mentenanţa sistemelor: MDD, dezvoltare.
Cursul 13 – 11 Ianuarie 1 Despre examen TAIP: ◦ 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 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 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 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 (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 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 8 9 10 Arhitectură și dependințe: Când spunem că Principii de proiectare a claselor: Principii de proiectare a arhitecturii: avem un proiect degradat? responsabilitate, dependențe, separare ◦ Reutilizare, versionare, închidere ◦ Cuplare, dependențe Șabloane de proiectare OO: ◦ Abstract server, Adapter, Observer, Bridge, Abstract Factory 11 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 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 condusă de model Dezvoltare agilă condusă de model Dezvoltarea condusă de domeniu Dezvoltare condusă de teste Refactorizare 14 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 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 AMDD este versiunea agilă a MDD 17 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 Unit testing Integration testing Functional testing Acceptance testing Performance testing 19 Schimbările succesive conduc la o structură sub-optimă 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 Schimbările pot introduce noi defecte Refactorizarea nu se referă la introducerea de noi funcționalități ◦ Refactorizarea trebuie efectuatã în pași mici ◦ Trebuie să existe teste care să indice locurile unde apar erori ◦ 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 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 23 BPMN Limbaje specifice domeniu (DSL) Cadre de lucru: ◦ Eclipse Modeling Framework ◦ Open Architecture Ware (OAW) 24 Business Process Modelling Notation (BPMN) is a graphical representation for specifying business processes in a workflow 25 26 EMF is an Eclipse-based modeling framework and code generation facility for building tools and other applications based on a structured data model 27 SOA: http://www-01.ibm.com/software/solutions/soa/ , http://ro.wikipedia.org/wiki/SOA SOA for the real world: http://www.javaworld.com/javaworld/jw11-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/IP11_Implementarea.pdf OAW http://www.openarchitectureware.org/ 28 Robert Cecil Martin: Design Principles and Design Patterns. www.objectmentor.com. Robert Cecil Martin: Agile Development. Principles, Patterns, and Practices, Prentice-Hall, 2003 29 Vă Mulţumesc! Pentru prezenţă, răbdare, colaborare... 30