Presentation is loading. Please wait.

Presentation is loading. Please wait.

Cursul 13 – 11 Ianuarie 1.  Despre examen  TAIP: ◦ Design orientat obiect: SOA, principii de design orientat obiect ◦ Dezvoltarea şi mentenanţa sistemelor:

Similar presentations


Presentation on theme: "Cursul 13 – 11 Ianuarie 1.  Despre examen  TAIP: ◦ Design orientat obiect: SOA, principii de design orientat obiect ◦ Dezvoltarea şi mentenanţa sistemelor:"— Presentation transcript:

1 Cursul 13 – 11 Ianuarie 1

2  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

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

4 4  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)

5 5  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)

6  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

7  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 8

9 9

10 10

11  Arhitectură i dependine: Când spunem că avem un proiect degradat?  Principii de proiectare a claselor: responsabilitate, dependene, separare  Principii de proiectare a arhitecturii: ◦ Reutilizare, versionare, închidere ◦ Cuplare, dependene  abloane de proiectare OO: ◦ Abstract server, Adapter, Observer, Bridge, Abstract Factory 11

12  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ă  Repetiie suplimentară  Opacitate – greu de îneles 12

13  Responsabilitate unică (coeziune)  Deschis-închis (eliminarea modificărilor în cascadă)  Substituiei (Liskov) - Subclasele se pot pune oriunde apar clasele lor de bază  Principiul inversării dependenelor (Hollywood)  Separarea interfeelor - Programele client nu trebuie forţate să depindă de metodele pe care nu le folosesc 13

14  Dezvoltarea condusă de model  Dezvoltare agilă condusă de model  Dezvoltarea condusă de domeniu  Dezvoltare condusă de teste  Refactorizare 14

15  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 înelese de utilizator, urmând ca pe baza acestora să se construiască sistemul final 15

16  MDA este cea mai cunoscută iniiativă din MDD i a fost lansată de grupul OMG (Object Management Group) în 2001  MDA are la bază un set de reguli pentru realizarea specificaiilor, 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, obinând ceea ce e mai bun în ambele direcii 16

17  AMDD este versiunea agilă a MDD 17

18  Test-Driven Development – TDD Paii TDD: 1. Adăuga un test. 2. Executa testele; testul nou euează. 3. Actualizează codul funcional a.i. să treacă toate testele. 4. Execută testele din nou. ◦ Dacă testele euează, treci la 3. ◦ Dacă testele trec cu succes, putem continua cu altă funcionalitate 5. Restructurează codul funcional i de testare 18

19  Unit testing  Integration testing  Functional testing  Acceptance testing  Performance testing 19

20  Schimbările succesive conduc la o structură sub-optimă a codului ◦ Crete complexitatea ◦ Scade claritatea  Refactorizarea este o schimbare în structura internă a unui produs software cu scopul de a-l face mai uor de îneles i de modificat fără a-i schimba comportamentul observabil  Rezultate: ◦ Scăderea cuplării ◦ Creterea coeziunii 20

21  Schimbările pot introduce noi defecte ◦ Refactorizarea trebuie efectuatã în pai mici ◦ Trebuie să existe teste care să indice locurile unde apar erori  Refactorizarea nu se referă la introducerea de noi funcionalităi ◦ Cele două activităi trebuie despărite  Refactorizarea îmbunătăete 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

22  Următoarele situaii sunt semnale pentru necesitatea refactorizării: ◦ Cod duplicat ◦ Metode lungi ◦ Clase mari ◦ Liste lungi de parametri ◦ Instruciuni switch după tipul obiectelor - Se recomandã polimorfismul ◦ Generalitate speculativă - Ierarhie de clase în care subclasele au acelaii comportament ◦ Comunicare intensă între obiecte (cuplare puternicã) ◦ Înlănuirea de mesaje 22

23 23

24  BPMN  Limbaje specifice domeniu (DSL)  Cadre de lucru: ◦ Eclipse Modeling Framework ◦ Open Architecture Ware (OAW) 24

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

26 26

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

28  SOA:  SOA for the real world: /jw-1129-soa.html?page=1http://www.javaworld.com/javaworld/jw /jw-1129-soa.html?page=1  Abstract Server  Agile Model Driven Development (AMDD)  Florin Leon – IP Curs 11  OAW 28

29  Robert Cecil Martin: Design Principles and Design Patterns.  Robert Cecil Martin: Agile Development. Principles, Patterns, and Practices, Prentice-Hall,

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


Download ppt "Cursul 13 – 11 Ianuarie 1.  Despre examen  TAIP: ◦ Design orientat obiect: SOA, principii de design orientat obiect ◦ Dezvoltarea şi mentenanţa sistemelor:"

Similar presentations


Ads by Google