Proiectarea si Arhitectura Sistemelor Software Complexe Conf dr

  • Slides: 13
Download presentation
Proiectarea si Arhitectura Sistemelor Software Complexe Conf. dr. ing. Ioana Şora www. cs. utt.

Proiectarea si Arhitectura Sistemelor Software Complexe Conf. dr. ing. Ioana Şora www. cs. utt. ro/~ioana. sora@cs. upt. ro

Obiectul cursului • Parte din directia de “Software Engineering” Fundamente de Inginerie Software Tehnici

Obiectul cursului • Parte din directia de “Software Engineering” Fundamente de Inginerie Software Tehnici de programare Programare OO Structuri de Date Algoritmi Proiectarea Detaliata a Sistemelor Software Proiectarea si Arhitectura Sistemelor Software Complexe Sisteme de operare Retele de Calculatoare

Motivatie

Motivatie

Motivatie • Articol: – Richard E. Fairley and Mary Jane Willshire: “Why the Vasa

Motivatie • Articol: – Richard E. Fairley and Mary Jane Willshire: “Why the Vasa Sank: 10 Problems and Some Antidotes for Software Projects”, in IEEE Software, March/April 2003 • • http: //www. cse. ogi. edu/~dfairley/The_Vasa. pdf http: //cpd. ogi. edu/seminars 04/Vasa. Presentation. pdf

Concluzie articol – cele 10 probleme: Problema Antidot Termene de realizare nerealiste Estimari obiective;

Concluzie articol – cele 10 probleme: Problema Antidot Termene de realizare nerealiste Estimari obiective; Resurse mai multe/mai bune; Prioritizarea cerintelor; Release-uri. Cerinte in continua schimbare Dezvoltare iterativa; Change control/baseline management Absenta specificatiilor tehnice Scrierea specificatiilor initiale; Actualizarea specificatiilor in functie de evenimente; Managementul specificatiilor; Arhitect care se ocupa de acest lucru. Absenta documentatiei proiectului Elaborarea unui plan initial; Actualizarea planului in functie de evenimente; Managementul planului; Project manager care se ocupa de acest lucru. Inovatii excesive Baseline control; Impact analysis; Continuous risk management; Arhitect care se ocupa de aceste lucruri. Inovatii inutile Cerinte contradictorii, haotice Initial requirements baseline; Baseline management; Risk management; Arhitect care se ocupa de aceste lucruri. Lipsa unor metode stiintifice Prototyping; Incremental development; Technical performance measurement Ignorarea unor probleme evidente Back-of-the-envelope calculations; Invatarea din erori Lipsa de etica profesionala Respectarea individuala a unui cod de etica

ABC: Architecture Business Cycle • Cazul ideal (dar depasit): proiectantul primeste cerintele (requirements) pe

ABC: Architecture Business Cycle • Cazul ideal (dar depasit): proiectantul primeste cerintele (requirements) pe care trebuie sa le rezolve sistemul si produce proiectul • Cerintele care trebuie luate in considerare in procesul de proiectare arhitecturala a unui sistem nu se rezuma doar la cerintele functionale (care descriu “ce face sistemul”) • Cerinte (calitati) non-functionale (qualities): performance, reliability, availability, platform compatibility, memory utilization, network usage, security, modifiability, usability, interoperability • Arhitectura unui sistem este rezultatul unui set de deciziii tehnice, economice si manageriale • Stakeholders: toate persoanele sau organizatiile care au o influenta asupra arhitecturii sistemului si care impun cerinte functionale si non -functionale: – Managerii organizatiei care realizeaza proiectul, Departamentul de marketing, Utilizatorii finali, Clientii, Departamentrul de intretinere (maintenance), … – Exemplu: Program de evidenta a salariatilor de la firma XYZ SRL

Stakeholders [Bass]-Fig. 1. 2

Stakeholders [Bass]-Fig. 1. 2

Influente asupra arhitecturii • Stakeholders – Fiecare stakeholder are vederi si interese diferite, uneori

Influente asupra arhitecturii • Stakeholders – Fiecare stakeholder are vederi si interese diferite, uneori contradictorii, asupra produsului • Organizatia care realizeaza proiectul – Obiectivele in business pe termen scurt si pe termen lung, resursele disponibile (personal, timp, buget) • Pregatirea si experienta proiectantilor – Repeta retetele de succes, evita repetarea greselilor anterioare • Mediul tehnic/tehnologic – Practici industriale standard • Implicatii colaterale acestor influente: – Majoritatea cerintelor sunt ascunse la inceput, nu sunt exprimate explicit si uneori nu sunt constientizate => trebuie identificate cat mai devreme – Architecture reviews & iterative prototyping

Architecture Business Cycle [Bass]-Fig. 1. 3

Architecture Business Cycle [Bass]-Fig. 1. 3

Rolul proiectului arhitecturii software • Gasirea solutiei de compromis intre cerintele (contradictorii) ale diferitelor

Rolul proiectului arhitecturii software • Gasirea solutiei de compromis intre cerintele (contradictorii) ale diferitelor categorii de stakeholders; stabilirea calitatilor dorite (qualities) ale sistemului • Proiectul arhitecturii sistemului reprezinta: – Abstractizare a sistemului, care omite detalii de implementare, algoritmi si reprezentare a datelor si pune in evidenta comportarea sistemului sub forma interactiunii unor componente de tip black-box. – Punct de start (project blueprint) pentru realizarea sistemului • Importanta proiectului arhitecturii software: – Primul pas din realizarea sistemului, efectuat in directia asigurarii calitatilor dorite ale acestuia – Primul artifact care permite analiza viitorului sistem in vederea stabilirii calitatilor acestuia

Continutul cursului • Conceptul de arhitectura software – Ce este arhitectura software ? –

Continutul cursului • Conceptul de arhitectura software – Ce este arhitectura software ? – Stiluri si tipare arhitecturale (Architectural pattern) fundamentale – Structuri arhitecturale • Crearea unei arhitecturi software – Calitati si Tactici arhitecturale – Documentarea • Analiza unei arhitecturi – Reconstructia – Metode de analiza • Reutilizarea la nivel arhitectural – Linii de produse software – Componente • Standarde industriale de infrastructuri de calcul – Exemplu: Microsoft. NET – Arhitectura – Componente – Interoperabilitatea intre limbaje

Bibliografie curs • L. Bass, P. Clements, R. Kazman: “Software Architecture in Practice”, 2

Bibliografie curs • L. Bass, P. Clements, R. Kazman: “Software Architecture in Practice”, 2 nd Edition, Addison Wesley, 2003 [Bass] • P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord, J. Stafford: “Documenting Software Architectures: Views and Beyond”, Addison Wesley, 2002. [Clements] • F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal: “Pattern Oriented Software Architecture, Vol 1: A System of Patterns”. J. Wiley&Sons, 1996. [POSA 1] • J. Richter: “The. NET Framework”, Microsoft Press, 2002. Si in traducere in lb romana la Ed Teora [NET] • Slide-uri: www. cs. utt. ro/~ioana

Laborator • Si totusi scriem si cod ; -) • 3 -4 teme: –

Laborator • Si totusi scriem si cod ; -) • 3 -4 teme: – Teme individuale – Teme de grup cu contributii individuale prestabilite – 50% din nota finala • Alcatuirea grupelor: – Inscrieri pentru cele 5 intervale prevazute in orar – maxim 18 studenti/grupa • Software utilizat: – Poate fi descarcat prin programul Microsoft Academic: – Microsoft Visual Studio: limbajul de implementare la alegere dintre C#, C++, J# –. NET Framework – Temele realizate trebuie sa poata fi compilate si rulate pe sistemele din laborator