Proiectarea arhitecturilor Principii de proiectare OO

1. ProiectareaarhitecturilorPrincipii de proiectare OO doctorandIonuț Apetrei

2. Agendă • 1. Principii ale proiectării arhitecturilor software • 2. Probleme întâlnite în sistemele software • 3. Utilizarea paradigmei ”Orientate-Obiect” în ingineria software: • 3.1 Principiul responsabilităţii unice –SRP • 3.2 Principiuldeschis-închis– OCP • 3.3 Principiulsubstituţiei - Liskov - LSP • 3.4 Principiul inversării dependenţelor – DIP • 3.5 Principiul separării interfeţelor - ISP

3. 1. Principii ale proiectării arhitecturilor software • Metode de organizare a arhitecturilor software • metoda multistratificată • stratul 1: şabloane de arhitectură– esențial pentru stabilirea formei și structurii unei aplicații • stratul 2 : modul în care este alcătuită arhitectura va releva domeniul aplicației software • 2.1 întâlnim subsisteme • 2.2 este necesară stabilirea modului de comunicare între subsisteme • stratul 3: se urmărește definirea arhitecturii modulelor și a modului în care acestea sunt legate. Vor fi folosite șabloane de proiectare, pachete, componente software și clase.

4. 2. Probleme întâlnite în sistemele software (1) • Context: există o prima versiune a sistemului, o implementare. Pe parcursul întreținerii sistemului apar diferite probleme (realizarea proiectării inițiale defectuoase, apariția de noi requirment-uri). • Semne : • arhitectură stufoasă, degradată • greutăți în întreținerea sistemului • Soluții : • analiza unei posibile reproiectări , analiză realizată de project manageri, arhitecți software și programatori • realizarea reproiectării (atenție la reproiectare)

5. 2. Probleme întâlnite în sistemele software (2) • Ce presupune o arhitectură problematică? • Caracteristicile unei astfel de arhitecturii sunt: • Rigiditate - în cazul unui sistem software, arhitectura acestuia este greu de schimbat. Orice modificare produce nevoia unei serii de schimbări în cascada în alte subsisteme ale aplicației. • Fragilitate - odată produse schimbările, acestea vor determina apariția unor defecte ale sistemului în module care nu au nici o legatură (la nivel logic) cu modulul în care s-au realizat ajustările. • Imobilitate -face trimitere la imposibilitatea de a descompune un sistem în componente ce pot firefolosite eventual în alte aplicații software

6. 2. Probleme întâlnite în sistemele software (3) • Vâscozitate - proprietatea unui sistem de a implementa funcționalitățile intrinseci, fără o elaborare judicioasă a arhitecturii și a separării conceptelor specifice domeniului aplicației. • Complexitate – situație în care un sistem software are în spate o arhitectură stufoasă, fară un beneficiu real. • Repetiție – aplicația deține concepte și structuri asemănătoare ce pot fi sintetizate în cadrul unei singure abstractizări. • Opacitate – implementarea sistemului, aplicației se înțelege greu, nu reflectă imediat funcționalitățile de bază.

7. 3. Utilizarea paradigmei ”Orientate-Obiect” în ingineria software (1) • Principii în proiectarea claselor • 3.1 Principiul responsabilităţii unice –SRP („ Single Responsibility Principle”) • Enunț: Orice clasă trebuie să aibă un singur motiv pentru modificare • Context: • fiecareresponsabilitate a claseieste o direcţie de schimbare • modificarea cerințelor, implică o modificare a responsabilităţilor clasei • Posibile probleme: • responsabilităţile devin cuplate, legate • modificarea unei responsabilităţi poate afecta modul în care clasa realizează celelalte responsabilităţi • rezultă clase fragile • Soluții: separarea responsabilităților

8. 3. Utilizarea paradigmei ”Orientate-Obiect” în ingineria software (2)

9. 3. Utilizarea paradigmei ”Orientate-Obiect” în ingineria software (3) • 3.2 Principiuldeschis-închis– OCP („Open-Closed Principle ”) • Enunț: Entităţile soft (clase, module, funcţii etc.) trebuie să fie deschise la extindere şi închisela modificare. • Context: modificarea unei entităţi implică o cascadă de modificări în alte entităţi • Posibile probleme: se obține o rigiditate a sistemului • Soluții: • se apelează la refactorizare astfel ca viitoarele modificări (de acelaşi tip) să nu producă noicascade de modificări • abstractizarea însoțită de separarea funcţionalităţilor generice de implementarea detaliată a acesteia

10. 3. Utilizarea paradigmei ”Orientate-Obiect” în ingineria software (4) • Proprietățile subsistemelor ce respectă OCP: • deschispentruextindere: în ceea ce privește comportamentulunui subsistem, acesta se poateextinde– extinderea se face prinscriere de cod nou, mai exact prin subclasenoi • închis pentru modificare: nu se modifică codul sursă sau codul binar al subsistemului vizat • Exemple: • programare bazată pe implementare • programare bazată pe interfețe – respectă OCP

11. 3. Utilizarea paradigmei ”Orientate-Obiect” în ingineria software (5) • 3.3 Principiulsubstituţiei - Liskov - LSP („ LiskovSubstitution Principle ”) • Enunț: Subclasele se pot pune oriunde apar clasele lor debază.Instanţele subclaselor pot înlocui instanţele claselor de bază. • Context: Face referire la proiectarea bazată pe contract. Clientul clasei de bază trebuie să funcţioneze normal în prezenţaclasei derivate • Exemplu:

12. 3. Utilizarea paradigmei ”Orientate-Obiect” în ingineria software (6) • 3.4 Principiul inversării dependenţelor – DIP („ Dependency Inversion Principle ”) • Enunț:Programele client trebuie să depindă de abstracţiuni, nu de lucruri concrete. • a. Modulele de nivel înalt trebuie să nu depindă de modulele denivel inferior. Toate modulele trebuie să depindă de abstractizări. • b. Abstractizările nu trebuie să depindă de detalii.Detaliile trebuie să depindă de abstractizări. • Context: • dependență: codulclientdepinde de funcţiişi clase concrete.Programul principal depinde de subprogramele care leapelează • inversarea dependenței:codulclientdepinde de interfeţe, funcţiişi clase abstracte. Subclasa depinde (de abstractizările definite) de clasa de bază

13. 3. Utilizarea paradigmei ”Orientate-Obiect” în ingineria software (7)

14. 3. Utilizarea paradigmei ”Orientate-Obiect” în ingineria software (8)

15. Sfârșit • Întrebări?