1 / 30

Tehnici Avansate de Ingineria Program ării

Tehnici Avansate de Ingineria Program ării. Cursul 1 3 – 11 Ianuarie. Cuprins. Despre examen TAIP: Design orientat obiect : SOA, principii de design orientat obiect

lance-weiss
Télécharger la présentation

Tehnici Avansate de Ingineria Program ării

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. TehniciAvansate de Ingineria Programării Cursul 13 – 11 Ianuarie

  2. Cuprins • 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

  3. Examenscris • 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

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

  5. Conținut TAIP (Cearfitrebuit să facem…) • Design orientat obiect clase: recapitulareGRASP ș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 • 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

  7. 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

  8. SOA – .NetROBOT – Tudor D.

  9. Implementing SOA the right way

  10. Principii de design OO • Arhitectură și dependințe: Când spunem că avem un proiect degradat? • Principii de proiectare a claselor: responsabilitate, dependențe, separare • Principii de proiectare a arhitecturii: • 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 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ă) • 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ţatesă depindă de metodele pe care nu le folosesc

  13. 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-drivendevelopment (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-drivenarchitecture • 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: separareadintre 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 condusă de teste • Test-DrivenDevelopment – TDD Pașii TDD: • Adăuga un test. • Executa testele; testul nou eșuează. • Actualizează codul funcțional a.i. să treacă toate testele. • Execută testele din nou. • 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. Refactorizare (Refactoring) • Schimbările succesive conduc la o structură sub-optimă acodului • Crește complexitatea • Scade claritatea • Refactorizarea este o schimbare în structura internă a unuiprodus software cu scopul de a-l face mai ușor de înțeles și demodificat 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 pași mici • Trebuie săexisteteste care săindicelocurileundeaparerori • Refactorizarea nu se referă la introducerea de noifuncționalități • Celedouăactivitățitrebuiedespărțite • Refactorizareaîmbunătățeștestructura, nu codul • Codulprostscris nu trebuierefactorizat, ci rescris • Refactorizarea nu trebuie să introducă niveluri de complexitateinutile • Costurilesuplimentare ale refactorizăriisunt compensate deeconomiileulterioare

  21. Refactorizare - Când? • Următoarele situații sunt semnale pentru necesitatearefactoriză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. 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 processes in a workflow

  25. BPMN - Example

  26. 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 • 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/IP11_Implementarea.pdf • OAW http://www.openarchitectureware.org/

  28. Bibliografie • 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...

More Related