Tipuri de Structuri arhitecturale. Documentarea arhitectrurii

1. Tipuri de Structuri arhitecturale.Documentarea arhitectrurii • Ce este si ce nu este arhitectura software • Tipuri de vederi structurale • Documentarea arhitecturilor software • IEEE Standard 1471-2000-2007: “Recommended Practice for Architectural Description of Software-Intensive Systems” • Notatii si limbaje utilizate pentru documentare

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

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

4. 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, Clements, Kazman)

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

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

7. Exemplul 1: Modulul M -> M2 Exemplul 2: arhitectura layered L1 M L2 M2 L3 Care e diferenta intre arhitectura si design ? (cont) • Elemente arhitecturale vs elemente nearhitecturale (cont): • 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, M2 este element nearhitectural ca urmare a deciziei proiectantului arhitecturii sistemului • Un modul de tip M2 poate fi atat element arhitectural cat si nearhitectural • Concluzie: (Clements&al): “Architecture is in the eye of the beholder”

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

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

10. Tipuri de structuri arhitecturale si vederi structurale • Module: • Decomposition • Uses (Layers) • Generalization • Component-and-Connector: • Datastream (Pipes-and-filters) • Call-return (Client-server, Peer-to-peer) • Shared-data (Blackboard, Repository) • Publish-subscribe (Implicit invocation, Event-only) • Communicating processes (Master-Slave) • Allocation: • Deployment • Implementation • Work assignement

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

12. Module: Decomposition Structure • Relatia A is-part-of B: defineste o relatie intre submodulul A si modulul agregat B • Restrictii: un modul poate fi parte din cel mult un modul agregat • Arata cum sunt partitionate responsabilitatile sistemului intre mai multe module • Realizarea descompunerii si a modulelor: build, buy, or reuse? • Vizibilitatea submodulelor poate fi controlata prin prescriptiile arhitectului • Un submodul vizibil in exterior poate fi utilizat (relatia uses) de alte module • Utilizare: • Intelegerea functionarii sistemului si a implementarii • Planificarea proiectului si resurselor necesare, alocarea sarcinilor echipei de dezvoltare • De obicei este startul oricarui proces de proiectare -> corespunde stilului de abordare divide-and-conquer • Determina mare parte din proprietatea de modifiability a sistemului

13. Module: Uses Structure • Relatia depends-on, specializata in uses • Alte specializari ale relatiei depends-on: includes, inherits from • Stilul Uses specifica constrangeri asupra modului de implementare: pentru fiecare modul specifica modulele cu care e in relatie uses sau is-allowed-to-use • Ce se intelege de fapt prin relatia uses ? • P uses Q if P depends on Q for functional correctness • P uses Q nu este echivalent cu P calls Q: • P uses Q, dar NU si P calls Q: De exemplu, P se bazeaza pe valoarea unei variabile comune setata de Q; sau P este un proces in stare de sleep care asteapta un semnal de la Q • P calls Q, dar NU si P uses Q: Q este un exception handler pe care P il apeleaza in situatii de erori; Nu este relatie uses pentru ca functionalitatea lui P nu este afectata de ce anume face Q • Utilizare: • Planificarea dezvoltarii incrementale • Impact analysis

14. Module: Generalization Structure • Relatia A is-a B: defineste o relatie de generalizare intre un modul specific A (element child) si un modul mai general B (element parent). Elementul child poate fi utilizat in orice context unde este utilizat elementul parent. • Variante: • Interface inheritance • Implementation inheritance • Utilizare: • Suport pentru extinderea si evolutia arhitecturii • Suport pentru re-use • OOD

15. 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 • Maparea vederilor din tipul Module pe vederi din tipul Component-and-connector • Rareori este de tip one-to-one • Destul de frecvent este de tip one-to-many • Pot apare si cazuri complexe in care fragmente de module corespund unor fragmente de componente

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

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

18. Exemplu: structura C&C

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

20. Component-and-Connector: Datastream Structure • Exemplu de specializare a structurii Datastream: stilul Pipes-and-Filters • componentele comunica prin intermediul unor asynchronous, buffered data streams • Adecvat sistemelor a caror comportament poate fi descris in mod natural sub forma unui graf de transformari, unde nodurile sunt unitati procesatoare iar arcele indica fluxurile de date intre acestea • Elemente: Filter: componente procesatoare de date, au 1 sau mai multe porturi de intrare si 1 sau mai multe porturi de iesire • Conectori: Pipe: conector binar unidirectional, transmite fluxul de date de la un port de iesire al unui filtru spre un port de intrare al altui filtru • Caracteristici: • Deoarece conectorii pipe buffereaza datele, filtrele pot opera asincron si concurent; Un filtru nu trebuie sa cunoasca identitatea filtrelor de la care primeste sau la care transmite date • Utilizare: • Analiza functionala • Analiza performantelor sistemului (input-output latency, schedulability)

21. Component-and-Connector: Shared-data Structure • Elemente: • Data repositories • Data accessors • Componentele de tip data accessor citesc date de la componentele de tip repository, efectueaza calcule si scriu rezultatele in repository • Componentele repository indeplinesc functiile de: asigura acces comun la date, persistenta datelor,accesul concurent la date • Conectori: de tip read data si write data • Relatii: definesc ce data accessors sunt conectati la ce data repositories • Substiluri: • Repository • Blackboard • Utilizare: • Analiza performantelor sistemului: performance, security, privacy, reliability • Asigurarea integritatii datelor

22. Component-and-Connector: Publish-subscribe Structure • Elemente: componente independente care interactioneaza prin evenimente. • Componentele sunt decuplate: nici o componenta nu stie care sunt alte componente au subscris la evenimentele sale • Conectori: de tip publish-subscribe. • Necesita o infrastructura care sa asigure faptul ca un eveniment produs ajunge la toate componentele care au subscris la el • Relatii: ce tipuri de evenimente publica fiecare componenta si la ce tipuri de evenimente subscrie fiecare componenta • Substiluri: • Implicit invocation • Event-only • Utilizare: • Exprima comunicarea prin mesaje (evenimente) intre participanti necunoscuti • Decuplarea permite intarzierea legarii producatorilor de evenimente de consumatorii de evenimente pana in momentul executiei

23. Component-and-Connector: Call-return Structure • Componentele interactioneaza prin faptul ca solicita servicii de la alte / furnizeaza servicii pentru alte componente. • Interactiunile=invocarea de servicii • in mod tipic, au loc sincron (solicitantul se blocheaza pana primeste raspunsul) • reprezinta o generalizare a apelului de functii din lb de programare • Substiluri: • Client-server • Peer-to-peer

24. Client-Server / Peer-to-Peer Style • Tipuri de componente: • Client: solicita servicii de la alte componente • Server: furnizeaza servicii altor componente • Peer: Componenta care inglobeaza atat comportament de Client cat si de Server • Proprietati: numarul si tipul clientilor care se pot conecta, proprietati de performanta (de ex nr tranzactii pe secunda) • Tipuri de conectori: • Request-reply: operatie (sincrona) de invocare de servicii de la client la server • Proprietati: protocolul de interactiune: un conector poate defini unul sau mai multe tipuri servicii invocate. In cazul in care prin acelasi conector se invoca mai multe servicii, este nevoie de un protocol care sa stabileasca ordinea in care acestea pot fi invocate • Relatii: attachments: determina ce clienti pot solicita anumite servicii • Model computational: clientii initiaza activitatile, solicitand servicii de la servere, apoi asteapta rezultatele acestor cereri. • Topologie: se pot specifica posibile constrangeri privitoare la: • Numarul de legaturi(attachments) pentru anumite porturi/roluri • Relatii intre servere • Tiers => N-tiered client server model

25. Component-and-Connector: Process Structure • Componente: unitati concurente (task, proces, fir de executie) • Proprietati: daca este sau nu preemptabila; prioritatea pentru planificarea in mediu de executie multitasking; , which influences scheduling; parametrii de timp (periodicitate, deadlines) • Conectori: comunicare intre unitati concurente “synchronizes with”, “starts”, “communicates with”, “wait for”) • Proprietati: Modul de comunicare sincron sau asincron; protocolul de comunicare. • Substiluri: • Watchdog • Resource synchronisation • Utilizare: • Identificarea locurilor in care apare competitia pebtru resurse partajate • Identificarea imprejurarilor in care firele de executie (procesele) sunt create sau distruse

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

27. Relatia Module – C&C • Acelasi modul poate fi executat in mai multe componente • Aceeasi componenta poate executa cod din mai multe module [Clements] – fig.3.5

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

29. Documentarea arhitecturii software • Rolul documentatiei arhitecturii: • Baza de comunicare intre stakeholders • Permite analiza: • Quality attributes • Behavior • Evolution and extension • Ce informatii trebuie sa cuprinda documentatia arhitecturala? • Structuri arhitecturale diferite => Vederi (Views) diferite • Informatii diferite urmarite => selectia vederilor documentate se face in functie de acestea • Categorii diferite de stakeholders => selectia vederilor documentate se face in functie de acestea

30. Informatii aduse de diferite vederi structurale [Bass] – Tab.2.1. Module C&C Allocation

31. Utilizari ale descrierii arhitecturale [Bass] – Tab.9.1.

32. Caror stakeholderi se adreseaza diferite vederile structurale [Bass] – Tab.9.2.

33. IEEE Standard 1471 • IEEE Standard 1471-2000-2007: “Recommended Practice for Architectural Description of Software-Intensive Systems” • Architectural Description: colectie de produse care sunt utilizate pentru documentarea unei arhitecturi • Ce NU impune IEEE 1471: NU impune un anumit format, limbaj sau formalism pentru descrierea arhitecturala • Ce Recomanda IEEE 1471: recomanda un anumit continut (o anumita structura a continutului si anumite aspecte documentate)

34. IEEE 1471 – Main Concepts • Stakeholder: has interests in, or concerns relative to the system • View: a representation of a concrete system from a single perspective • an architectural description is organized into several views. A view addresses certain concerns of the stakeholders. • Viewpoint: a pattern (template) for representing a set of concerns relative to architecture. The viewpoint establishes conventions by which a view is created, depicted and analyzed. • A view conforms to a viewpoint. The viewpoint determines the languages (notation, models) to be used to describe the view • Putem considera ca un viewpoint este formalizarea unui viewtype • Architectural description: selects one or more viewpoints for use • IEEE nu impune un anumit set de vederi: acesta se determina in functie de interesele celor carora li se adreseaza documentatia

35. IEEE 1471 - Model for Architectural Description System has an Architecture has 1..* described by 1 Stakeholder identifies Architectural Description is important to 1..* organized by 1..* selects 1..* has 1..* Concern used to cover Viewpoint conforms to View

36. Viewpoints: Module C&C Allocation Notatii: Notatii informale boxes-and-lines UML Diferite diagrame ADL’s (Architectural Description Languages) Diferite limbaje Descrierea arhitecturala

37. Module: Class, Package Relatii: Class diagrams Exemplu descriere Module UML

38. Descriere C&CCe trebuie sa descrie? • Elemente: • Componente , Porturi • Conectori, Roluri • Relatii: attachement • componenta.port <-> conector.rol

39. Exemplu descriere C&CNotatie Informala – Boxes-and-lines • Notatiile informale pot fi utile, cu conditia sa existe o intelegere clara (o legenda) a simbolurilor folosite [Clements] – fig.4.2

40. Exemplu descriere C&CUML : optiunea 1 : Class-Object Nu ofera suport adecvat pentru reprezentarea porturilor si conectorilor [Bass] – Fig. 9.10

41. Exemplu descriere C&CUML 2.0 : optiunea 2: UML Components Introduce reprezentare pentru porturi. Nu reprezinta conectorii. [CMU/SEI-2004-TR-008]

42. Interfaces: Provided Interfaces: descriu operatiile publice (features) care constituie un serviciu furnizat Required Interfaces: nou din UML 2.0: descriu features care constituie un serviciu de care depinde serviciul furnizat UML 2.0 new concepts: Interfaces Element cu o interfata provided si una required Realization relation: provided interface Dependency relation: required interface

43. Port: concept asemanator cu interface – descrie cum un element interactioneaza cu mediul Diferenta fata de interface: fiecare port reprezinta un punct de interactiune distinct Fiecare port are un tip Poate fi asociat cu descrieri comportamentale (protocol state machines) Fiecare port poate fi asociat cu un numar de interfete de tip provided si/sau requested UML 2.0 new concepts: Port

44. Component: a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment Subtype of class in the UML metamodel Permite: subtyping through generalization, behavioral description, internal structure, ports, interfaces, instantiation In plus fata de class: mai multe tipuri de elemente decat class: packages, use cases; deployment specifications UML 2.0 new concepts: Component Vedere externa a unei componente cu porturi Vedere interna a unei componente cu porturi

45. Connector: communication link between two or more instances NU poate fi asociat cu descrieri comportamentale sau atribute Tipuri de conectori: Assembly connector: leaga o provided interface de o required interface sau doua porturi externe a doua componente Delegation connector: leaga un comportament extern (port) de realizarea sa interna UML 2.0 new concepts: Connector

46. Exemplu descriere C&CArchitectural description languages • Architectural description language: o notatie grafica sau textuala pentru descrierea unui sistem software in termenii de elemente arhitecturale si relatii intre acestea • Diferite ADL’s: • ACME • Wright

47. Acme: limbaj de descriere arhitecturala Exemplu descriere C&CAcme ADL Family PipeFilter = { Port Type OutputPort; Port Type InputPort; Role Type Source; Role Type Sink; Component Type Filter; Connector Type Pipe = { Role src : Source; Role snk : Sink; Properties { latency : int; pipeProtocol: String = . . . ; } }; };

48. Exemplu descriere C&CAcme ADL – Continuare exemplu System simple : PipeFilter = { Component Splitter : Filter = { Port pIn : InputPort = new InputPort; Port pOut1 : OutputPort = new OutputPort; Port pOut2 : OutputPort = new OutputPort; Properties {. . . } }; Component Grep : Filter = { Port pIn : InputPort = new InputPort; Port pOut : OutputPort = new OutputPort; }; Component MergeAndSort : Filter = { Port pIn1 : InputPort = new InputPort; Port pIn2 : InputPort = new InputPort; Port pOut : OutputPort = new OutputPort; Representation { System MergeAndSortRep : PipeFilter = { … } }; /*end Representation */ Connector SplitStream1 : Pipe = new Pipe; Connector SplitStream2 : Pipe = new Pipe; Connector GrepStream : Pipe = new Pipe; Attachments { Splitter.pOut1 to SplitStream1.src; Grep.pIn to SplitStream1.snk; Grep.pOut to GrepStream.src; MergeAndSort.pIn1 to GrepStream.snk; Splitter.pOut2 to SplitStream2.src; MergeAndSort.pIn2 to SplitStream2.snk; }; }; /* end System simple */

49. Exemplu descriere AllocationUML Deployment diagram