Proiectarea si Arhitectura Sistemelor Software Complexe Conf dr

Proiectarea si Arhitectura Sistemelor Software Complexe Conf. dr. ing. Ioana Şora www. cs. utt. ro/~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 • Complexitatea sistemului implica abordarea initiala la un nivel ridicat de abstractizare => “arhitectura software”

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 – Reuse: poate fi de software, design sau know-how • Mediul tehnic/tehnologic – Practici industriale standard la momentul respectiv – Tehnologii/tool-uri populare la momentul deciziei • 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

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

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 Baze de date

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

Resurse

Introducere in arhitectura software Bibliografie: [Bass] – chap 2: What is software architecture ? 2. 1. What software architecture is and what it is not 2. 5. Architectural structures and views 2. 3. Architectural concepts 2. 4. Why is software architecture important ?

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

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)

Arhitectura software – definitia explicata • Elemente: (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. • Structuri multiple: Arhitectura poate fi compusa din structuri (vederi structurale) multiple. – De exemplu: • O vedere structurala asupra unui sistem poate captura relatiile dintre modulele in care este impartit proiectul in faza de dezvoltare. • O alta vedere structurala poate captura relatiile dintre elementele care apar in timpul executiei programului – 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. • Comportamentul elementelor (behaviour): – Partea observabila din exterior a comportamentului elementelor face parte din arhitectura

Care e diferenta intre arhitectura si design ? • “Architecture is design but not all design is architecture” (Clements&al) – Multe decizii privitoare la design nu sunt luate de arhitectura, ci sunt lasate la latitudinea proiectantului de detaliu si implementatorului • Ce decizii sunt ne-arhitecturale ? – Cele care se refera la elemente ale caror proprietati nu sunt vizibile din exterior – Exemplu: • prescriptie arhitecturala: Modulul M trebuie sa furnizeze apelantilor sai o modalitate de a salva si regasi date • decizii nearhitecturale: structurile de date (lista, tablou, etc) si algoritmii utilizati pentru implementare • Elemente arhitecturale vs Elemente nearhitecturale – Elemente nearhitecturale: ar putea fi acele elemente a caror existenta este necunoscuta in afara unui anumit context (unei anumite interfete) ?

Care e diferenta intre arhitectura si design ? (cont) • Elemente arhitecturale vs elemente nearhitecturale (cont): Exemplul 1: Modulul M -> M 2 Exemplul 2: arhitectura layered L 1 M M 2 L 3 • • • Faptul ca existenta unui element “nu este cunoscuta in afara unui context redus” nu este un bun criteriu pentru ca acesta sa fie declarat element nearhitectural ! In exemplul 1, M 2 este element nearhitectural ca urmare a deciziei proiectantului arhitecturii sistemului Un modul de tip M 2 poate fi atat element arhitectural cat si nearhitectural • Concluzie: (Clements&al): “Architecture is in the eye of the beholder”

Structura/Structurile unui sistem • Categorii de decizii pe care le implica proiectarea arhitecturala: – Cum se structureaza sistemul din punct de vedere al unitatilor de implementare (module) ? – Care este structura sistemului din punct de vedere al elementelor care se identifica in timpul executiei si al interactiunilor acestora ? – Care sunt structurile non-software (hw, retele, echipa de dezvoltare) ? • Un sistem este descris prin mai mult de o singura structura: – Structura modulelor - structura statica a sistemului, rezulta in faza de design – Structura interactiunilor – structura dinamica din timpul executiei sistemului – Structurile allocation/deployment • Fiecarei structuri ii corespunde un tip de vedere structurala (Viewtype) – In cadrul unui tip de vedere structurala, se definesc Elemente permise si Tipuri de Relatii intre acestea • Descrierea arhitecturii sistemului trebuie sa contina, pe langa structuri, si descrierea comportamentala (behavior)

Tipuri de vederi structurale (Viewtypes) • Module (Design/Functional Structure) • Component and Connector (Runtime) • Allocation (Deployment, Physical Structure, Team Structure) • Cum se descrie fiecare tip de vedere structurala ? • La ce serveste fiecare tip de vedere structurala ? • Cum selectez vederile relevante ?

The Module Structure: Elements & Relations • Elemente: module – Unitate de implementare pentru software, care reprezinta o entitate coerenta din punctul de vedere al functionalitatii • Relatii: – Is-part-of: A is part of B – Depends on (Uses or Allowed to use) – Is-a: A is a B • Proprietatile elementelor: – Nume: de obicei contine informatia primara din care se poate “banui” rolul sau. Numele pot fi supuse restrictiilor spatiilor de nume. – Responsibilitatile: rolul modulului trebuie descris in mai multe detalii decat simplul nume – Vizibilitatea interfetelor: in cazul submodulelor, se decide care dintre interfetele lor sunt sau nu vizibile din afara modulului care le contine – Informatii despre implementare: nu reprezinta neaparat informatii arhitecturale dar sunt utile la acest nivel: • Maparea module <-> unitati de cod de implementare (fisiere) • Test & management information • Implemention constraints

Module Structure: Concluzii • La ce e bun tipul de vedere Module: – Construction blueprints – Analysis • Impact analysis: prezice efectul modificarilor aduse sistemului; se bazeaza in special pe relatiile de dependenta • Traceability to functional requirements: cerintele functionale sunt suportate de responsabilitatile modulelor – Communication • Explain functionality • Relationships of system parts • La ce NU e bun tipul de vedere Module: – Comportamentul sistemului in timpul executiei – Runtime qualities: performance, reliability, etc. => pentru analiza lor sunt necesare vederi din tipul Component-and-Connector

Component-and-Connector: Overview • Reprezinta entitati care apar in timpul executiei programului • Nu reprezinta unitati de implementare • Analogie modelare UML: – Module Viewtype <-> Class Diagrams – Component&Connector View. Type <-> Object (Collaboration) Diagrams • Elementele sunt numite componente si conectori – Ambele categorii au semantici bine definite – Conectorii NU pot fi redusi la o subcategorie de componente

Component-and-Connector: Elements& Relations • Elemente: Componente – Unitati de procesare si Unitati de stocare de date – Se manifesta in timpul executiei, sub forma de: procese, obiecte, clienti, servere, baze de date, etc. – Porturi: “interfata” componentei la executie; puncte de (potentiala) interactiune cu mediul – Tipul unei componente: defineste functionalitatea generala a acesteia, numarul si tipul porturilor, proprietatile cerute; de exemplu, o componenta de tip “filter” proceseaza fluxuri (stream) de intrare primite pe porturile de tip “input”, rezultand fluxuri de iesire la porturile “output”. • Conectori – mecanisme de interactiune intre componente – Se manifesta sub forma de apeluri de procedura, mesaje, evenimente, pipes – Interactiunile pot fi si protocoale de comunicatie complexe, necesitand suportul infrastructurii precum middleware, sisteme de operare, etc. – Roluri: “interfetele”; de exemplu, un conector pipe poate fi descris avand 2 roluri, “writer” si “reader”. – Tipul unui conector: defineste natura interactiunilor, numarul si tipul rolurilor, proprietatile cerute • Relatii – attachment: definesc topologia sistemului – specifica ce porturi ale componentelor se leaga la anumite roluri ale conectorilor

Exemplu: structura C&C

Informatii aduse de vederea C&C • Care sunt elementele care apar in timpul executiei sistemului si interactiunile dintre ele ? Care este dinamica acestui aspect in cursul executiei ? • Care sunt principalele surse de date ? • Exista parti replicate in sistem ? • Care sunt fluxurile de date prin sistem ? • Ce protocoale de comunicatie utilizeaza elementele sistemului ? • Ce categorii de proprietati ale sistemului pot fi analizate pe baza vederii C&C ? – – – Reliability Performance Resource requirements Functionality Security

Module Viewtype – C&C Viewtype • Maparea este rareori de tip one-to-one, destul de frecvent este de tip one-to-many • Acelasi modul poate fi executat in mai multe componente • Aceeasi componenta poate executa cod din mai multe module [Clements] – fig. 3. 5

Allocation Structure • Deployment: – Descrie modul de mapare a elementelor software pe elemente hardware – Elemente: • Componente software, definite in C&C • Elemente de mediu: procesoare, elemente de stocare, de retea, etc. – Relatii: • Allocated-to, arata pe ce elemente de mediu sunt localizate elementele software • Migrates-to, copy-migrates-to, execution-migrates-to – Utilizare: analiza: performance, availability, security; estimare costuri. • Work assignement: – Elemente: • Software: module • Elemente de mediu: persoana, echipa, subcontractor, etc – Relati: Allocated-to – Utilizare: project management • Implementation: – Descrie maparea modulelor pe fisiere – Utilizare: Configuration control, integration, build testing

Relatia C&C - Allocation Exemplu: Vedere Combinata: 3 -Tiers combina Client-Server cu Deployment [Clements] – fig. 6. 16

Concepte Reference Model Reference Architecture Design Pattern Architectural Style Software Architecture 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. ” [POSA 1]/pag. 12 • Exemplu: Model-View-Controller

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. ” [POSA 1]/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 [POSA 1] • 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. [Go 4]” [POSA 1]/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. ” [POSA 1]/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”

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