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

Cand este un sistem software “complex” ? Functionalitate complexa Trebuie sa indeplineasca/gaseasca un compromis intre diverse cerinte ne-functionale (“ilities”) de multe ori contradictorii Stakeholders (factorii care iau decizii care influenteaza solutia): numerosi, de naturi foarte diferite, contradictorii

Stakeholders [Bass]-Fig.1.2

Cand este un sistem software “complex” ? Functionalitate complexa Trebuie sa indeplineasca/gaseasca un compromis intre diverse cerinte ne-functionale (“ilities”) de multe ori contradictorii Stakeholders (factorii care iau decizii care influenteaza solutia): numerosi, de naturi foarte diferite, contradictorii Echipa de dezvoltare => Project management Dezvoltarea lui utilizeaza diverse tehnologii/tool-uri/infrastructuri => Adaptarea la factori impusi => Respectarea unor conventii uzuale specifice Complexitatea sistemului implica abordarea initiala la un nivel ridicat de abstractizare => “arhitectura software”

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

Ce este si ce nu este arhitectura software? Exemplu: figura de mai jos intentioneaza sa descrie arhitectura unui sistem care simuleaza o problema de acustica subacvatica Se utilizeaza pentru descriere o notatie informala foarte “populara” de tip boxes-and-lines Ce se poate afla din aceasta figura ? Sistemul consta din 4 elemente Toate elementele prezinta relatii reciproce de o natura sau alta, diagrama este complet conectata Trei dintre elemente au probabil ceva mai multe in comun decat al 4-lea Bass – fig.2.1

Ce este si ce nu este arhitectura software? (cont) Ce NU se poate afla din aceasta figura ? Care este natura elementelor ? Care sunt responsabilitatile fiecarui element ? Care este semnificatia conexiunilor ? Care este semnificatia alinierii ? Concluzie: diagrama nu reprezinta o arhitectura software (sau cel putin nu e o reprezentare utila a unei arhitecturi software)

Arhitectura software - definitie “The software architecture is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements and the relationships among them” (Bass et al) Structure(s) – there’s more than one

Arhitectura software – definitia explicata “The software architecture is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements and the relationships among them” (Bass et al) Elemente software: (termenul element arhit. e de preferat celui de componenta arhit.) Arhitectura este o abstractizare a sistemului Arhitectura omite anumite detalii: se exclud acele proprietati ale elementelor care nu afecteaza modul cum elementele pot fi utilizate de alte elemente sau interactiunile intre elemente Proprietati vizibile din exterior: servicii furnizate, caracteristici de performanta, utilizarea resurselor partajate de mai multe elemente, etc.

Arhitectura software – definitia explicata “The software architecture is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements and the relationships among them” (Bass et al) Structuri multiple: Arhitectura poate fi compusa din structuri (vederi structurale) multiple: Structura modulelor - structura statica a sistemului, rezulta in faza de design Structura interactiunilor – structura dinamica din timpul executiei sistemului Structurile allocation/deployment - Descrie modul de mapare a elementelor software pe elemente non-software (hardware, de personal)

Arhitectura software – definitia explicata “The software architecture is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements and the relationships among them” (Bass et al) Structuri multiple: Arhitectura poate fi compusa din structuri (vederi structurale) multiple. Implicatii: Termenii “Elemente” si “Relatii intre elemente” pot avea diferite semnificatii: Elemente pot fi: obiecte, clase, functii, procese, programe, biblioteci, etc. Relatii/Interactiuni intre elemente: subdivizare, sincronizare, apel de functie, etc.

De ce e importanta arhitectura software? Pentru ca reprezinta: Mijloc de comunicare intre stakeholders Primele decizii de proiectare Abstractizare transferabila a unui sistem

Arhitectura ca mijloc de comunicare intre stakeholders Fiecare stakeholder este interesat de anumite caracteristici ale sistemului Rolul proiectantului arhitecturii: gasirea strategiilor de a echilibra caracteristicile diferite si/sau contradictorii Rolul arhitecturii: un limbaj comun in care se exprima, negociaza si rezolva aceste caracteristici Arhitectura e suficient de abstracta ca sa poata descrie la un nivel general inteligibil un sistem complex Arhitectura poat fi analizata din punct de vedere al principalelor caracteristici ale sistemului

Architectura ca decizie de proiectare Defineste unele constrangeri privind implementarea Influenteaza structura organizationala Promoveaza anumite calitati ale sistemului (modifiability, performance, safety, security, etc) Permite predictia calitatilor/proprietatilor sistemului Permite estimarea costurilor si termenelor de realizare

Arhitectura ca model transferabil, reutilizabil Reutilizarea arhitecturii - Software product lines Arhitectura poate fi realizata utilizand componente dezvoltate independent de externi

Arhitectura software Reprezinta: Ce terminologie ? De la ce se pleaca? Mijloc de comunicare intre stakeholders Primele decizii de proiectare Abstractizare transferabila a unui sistem Ce terminologie ? De la ce se pleaca? Terminologie comuna, bune practici, obiceiuri, standarde, solutii de succes cunoscute …. PATTERNS

Reference Architecture Architectural Pattern Software Architecture Concepte Reference Model Reference Architecture Design Pattern Architectural Pattern Software Architecture Architectural Style Framework

Architectural Pattern “An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.” [POSA1]/pag.12 Exemple: Model-View-Controller cu variante pentru GUI: Document-View (MFC), Model-View-Presenter sau aplicatii Web: Model-2 Broker

Architectural Style “An architectural style defines a family of software systems in terms of their structural organization. An architectural style expresses components and the relationships between them, with the constraints of their application, and the associated composition and design rules for their construction.” [POSA1]/pag.394 Exemplu: stilul Pipes-and-filters Componente: toate au acelasi tip, Filter. componente procesatoare de date, au 1 sau mai multe porturi de intrare si 1 sau mai multe porturi de iesire Relatii dintre 2 componente: conectori Pipe conector binar unidirectional care transmite fluxul de date de la un port de iesire al unui filtru spre un port de intrare al altui filtru Constrangeri si reguli: Un filtru nu trebuie sa cunoasca identitatea filtrelor de la care primeste sau la care transmite date

Relatia Architectural style ↔ Architectural pattern Unii autori [Bass] interpreteaza architectural style = architectural pattern Un stil arhitectural poate fi descris sub forma unui tipar arhitectural [POSA1] Diferente: Stilurile se refera la aspecte macro, legate de structura globala a unei aplicatii. Tiparele pot acoperi o gama larga de aspecte, de la arhitectura -> design -> limbaj Tiparele sunt mai concrete (mai orientate pe probleme concrete) Stilurile nu sunt legate de probleme sau domenii de aplicatie concrete

Design pattern “A design pattern provides a scheme for refining the subsystems of a software system, or the relationships between them. It describes a commonly-recurring structure of communicating components that solves a general design problem within a particular context. [Go4]” [POSA1]/pag.13 Tipare de scara mai mica decat cele arhitecturale Independente de un limbaj de programare (de obicei) independente de o paradigma de programare Aplicarea unor tipare din aceasta categorie nu afecteaza structura fundamentala a unui sistem

Reference Models “A reference model is a division of functionality together with data flow between the pieces. It is a standard decomposition of a known problem into parts that cooperatively solve the problem.” [Bass]/&2.3 Rezulta din experienta indelungata intr-un anumit domeniu de aplicatie Sunt caracteristice domeniilor mature Exemple: Compilatoare: analiza lexicala, analiza sintactica, analiza semantica, optimizare de cod, generare de cod, Retele: Modelul de referinta OSI

Reference Architectures “A reference architecture is a reference model mapped onto software elements (that cooperatively implement the functionality defined in the reference model) and the data flows between them.” [Bass]/&2.3 Reference model defineste o descompunere a functionalitatilor Reference architecture defineste modul de mapare a functionalitatilor pe niste definitii de subsisteme/componente Maparea poate fi 1-1 dar nu neaparat necesar Exemplu: CORBA (Common Object Request Broker Architecture)

Frameworks “A framework is a partially complete software system that is intended to be instantiated. It defines the architecture for a family of systems and provides the basic building blocks to create them.” [POSA1]/pag.396 Defineste locurile unde se pot face insertii/adaptari la instantiere: hot spots / frozen spots Instantierea: prin compunerea si subclasarea claselor furnizate de framework Diferenta framework ↔ reference architecture: un framework este dat sub forma de cod, reference architecture nu Diferenta framework ↔ biblioteca: la dezvoltarea unei aplicatii noi: biblioteca: scrii main body si utilizezi elemente (functii, clase, etc) din biblioteca framework: de obicei framework furnizeaza un main body predefinit, mai trebuie adaugate/concretizate unele elemente (functii, clase) pe care acesta le utilizeaza. “inversion of control”

Continutul cursului Conceptul de arhitectura software Ce este arhitectura software ? Stiluri arhitecturale fundamentale Pipes and filters Layers Blackboard Event-driven Arhitecturi tipice pe domenii/tipuri de aplicatii: Adaptive Reflective Distribuite Client-server, Broker Enterprise Data access Interoperability

Resurse Motivatie la motivatie: Editorii cartilor de specialitate din domeniu manifesta o tendinta in a incerca sa ne trezeasca interesul pentru subiect alegand pentru ilustrarea copertilor imagini metaforice cu tot felul de cladiri si monumente istorice